Leaderboard

http://xkcd.com/1319/ Enjoy!

I stumbled upon one resolution to this issue (air quotes, "issue") recently: Restart LabVIEW From the Getting Started Window, select "Tools >> Advanced >> Clear Compile Object Cache..." Clear both User and App Builder cache (my hunch is that the App Builder cache is not necessary; but why not) Restart LabVIEW Open the guilty lvproj Mass compile the project root Now, "Find Items Incorrectly Claimed by a Library" -- no more spurious ownership issues Anecdotally, it's not sufficient to clear the cache while the project is loaded (or, perhaps it might be sufficient with a subsequent reboot). Your mileage may vary.

This isn't a working solution but it might help. I would use 7-zip if the other native zip utilities don't like .GZ. .GZ is not a zip but many zipping tools support it. http://lavag.org/topic/16513-can-we-prevent-zlib-compress-dir-from-replacing-accented-characters/#entry101116 There someone asked about zipping a folder of files in a way that wasn't supported so I suggested using 7-zip in a command line to get the function needed. You can look at the code and modify it to extract the .GZ to a temp location and then you can read the files from there.

That is not a correct analysis and the solution is only one way to solve the problem. The real problem is not a relative path but simply the fact that your DLL depends on another DLL. No path is stored in your DLL to the other DLL, just its name. Windows when asked to load a DLL will scan the entire import list of that DLL and load any dependency of that DLL too. For that it looks in following locations: 1) It looks if the current process has already loaded a DLL with the same name, if so it is simply linked to the imports of the DLL currently loaded 2) It then looks in the same directory as the executable file of the current process 3) Next it will look in the <System> directory 4) Then in the 16 bit <system> directory 5) Then it will look in the <Windows> directory 6) Next is the current directory (that is the directory where the latest operation was done from inside the current process, that can be the double click to start the application or any file dialog box that is dismissed with anything but Cancel is selected, or an explicit call to the SetCurrentDirectory() API) 7) Last but not least it will look in any directory listed in the PATH environment variable In Windows XP and earlier point 6) is by default placed between 1) and 2) placing your secondary DLLs into the LabVIEW.exe directory is the safest location, but gets quickly a mess if you have more than one or two such DLLs. It is also a hassle to remember to include those DLLs into your application executable build and make sure they get into the root directory of your application. The proper solution is to have an installer for your DLL that takes care about installing all dependencies correctly too, and that installer should be created by the supplier of your DLL.