ejensen Posted February 5, 2009 Report Share Posted February 5, 2009 I have an EXE build specification for a project I'm working on. The project uses classes and overrides, but I have managed to get a fully working .exe by storing the classes as LLBs. The problem is, on alternate attempts to build the executable, it returns an error. If I close the error and try building again, it succeeds. If I try building again, it returns the same error. This behavior repeats indefinitely. This is more of a frustration than an actual problem for me, since I just have to try building a 2nd time to make it work. I have noticed that when it returns the error, it removes any old files from the build that were in the destination directory, but doesn't replace them as it would on a successful build. I was just hoping someone may have some insight in to why this might be happening. Googling has been no help so far. The error returned is as follows: An error has occurred. Expand the Details section for more information. Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference: Error 10 occurred at New VI Library.vi Possible reason(s): LabVIEW: Duplicate path. ========================= NI-488: Asynchronous I/O operation in progress. Quote Link to comment
Mark Smith Posted February 5, 2009 Report Share Posted February 5, 2009 QUOTE (ejensen @ Feb 4 2009, 10:11 AM) ... I have noticed that when it returns the error, it removes any old files from the build that were in the destination directory, but doesn't replace them as it would on a successful build...An error has occurred. Expand the Details section for more information. Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference: Error 10 occurred at New VI Library.vi Possible reason(s): LabVIEW: Duplicate path. ========================= NI-488: Asynchronous I/O operation in progress. I think you explained pretty well what happened - the app builder tries to write to some path (llb?) that already exists. The app builder fails, then cleans up after itself (I don't think it wants to leave any half-written files laying around). The next time, that path doesn't already exist so the app builder succeeds. I don't know why it won't overwrite or any of those details, but it sure sounds like the builder would succeed the first time if you clean out the destination folder first. Mark Quote Link to comment
ejensen Posted February 5, 2009 Author Report Share Posted February 5, 2009 Thanks for your reply. QUOTE (mesmith @ Feb 4 2009, 11:35 AM) I think you explained pretty well what happened - the app builder tries to write to some path (llb?) that already exists. I considered that, but have never encountered this before. The build always just overwrites the old files. QUOTE (mesmith @ Feb 4 2009, 11:35 AM) it sure sounds like the builder would succeed the first time if you clean out the destination folder first. I should have tried that before posting. I have confirmed that if I delete the files from the destination directory before building, I get no errors. Any ideas why this would be happening for this project, but not for any of the other projects I've built? Quote Link to comment
crelf Posted February 5, 2009 Report Share Posted February 5, 2009 QUOTE (ejensen @ Feb 4 2009, 12:43 PM) I have confirmed that if I delete the files from the destination directory before building, I get no errors. Any ideas why this would be happening for this project, but not for any of the other projects I've built? Are the files/folders in your biuld area under SCC? Quote Link to comment
ejensen Posted February 5, 2009 Author Report Share Posted February 5, 2009 QUOTE (crelf @ Feb 4 2009, 12:04 PM) Are the files/folders in your biuld area under SCC? No, I've never used SCC. This is the first time I've tried to build a project with classes. I also didn't mention it before, but I'm using LLBs renamed as DLLs as per the instructions here: http://digital.ni.com/public.nsf/allkb/472...62574AC006A258B. I don't know if that might have anything to do with it, but those are the only things I've done in this project that I haven't done in previous projects. Quote Link to comment
pallen Posted February 5, 2009 Report Share Posted February 5, 2009 QUOTE (ejensen @ Feb 4 2009, 03:09 PM) EDIT: I've investigated a bit more. I only received the error if there were DLLs left in the destination directory. The other files were overwritten as I would expect. If I leave the classes as LLBs instead of renaming as DLLs, the files overwrite normally and I do not get the error. It seems it doesn't like overwriting DLLs specifically, or perhaps just LLBs pretending to be DLLs. I know the workaround now, but I still find this behavior odd. Is it possible that your OS is setting those files as "Read Only" or something? Quote Link to comment
ejensen Posted February 5, 2009 Author Report Share Posted February 5, 2009 QUOTE (pallen @ Feb 4 2009, 02:25 PM) Is it possible that your OS is setting those files as "Read Only" or something? I considered that. I don't think that's what is happening because when it fails to overwrite the DLLs, it deletes them (and all other files in the build). If it is 'protecting' them from being overwritten, I wouldn't think it would then allow them to be deleted. Quote Link to comment
Rolf Kalbermatter Posted February 6, 2009 Report Share Posted February 6, 2009 QUOTE (ejensen @ Feb 4 2009, 02:09 PM) No, I've never used SCC.This is the first time I've tried to build a project with classes. I also didn't mention it before, but I'm using LLBs renamed as DLLs as per the instructions here: http://digital.ni.com/public.nsf/allkb/472...62574AC006A258B. I don't know if that might have anything to do with it, but those are the only things I've done in this project that I haven't done in previous projects. EDIT: I've investigated a bit more. I only received the error if there were DLLs left in the destination directory. The other files were overwritten as I would expect. If I leave the classes as LLBs instead of renaming as DLLs, the files overwrite normally and I do not get the error. It seems it doesn't like overwriting DLLs specifically, or perhaps just LLBs pretending to be DLLs. I know the workaround now, but I still find this behavior odd. The application builder stumbles over something that it does not expect since it usually doesn't happen but is caused by the workaround you have employed. Most likely it is the VI library code used in the Librarian VIs to deal with LLBs. That code contains some specific file ending checks that will fail on files with a DLL extension causing the following code to work badly when the file already exists. So the application builder will need to be fixed to workaround a bug caused by another workaround Rolf Kalbermatter Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.