LabVIEW
Exe fails to link to .NET DLL
Solved!
I've updated the version of a .NET DLL file (STILSensors.dll) used for comms with a connected instrument. I replaced the file in the project directory, I then had to click on every .NET node in the code to remake the links before it would run from source. When I run the exe, the dialog below appears, this happens every time I start the exe. I've checked the always included build options (data folder) and read the forums. Why does LabVIEW not recognise the dll file? and why does it prompt in the correct folder but cannot see the file? I figure LabVIEW is looking for the old version of the DLL, how do I re-create the link?
here are more screen shots to show the areas I have looked at so far:
mouse over the constructor node shows version 0.0.0.0. This was also the mouse over display prior to updating STILSensors.dll.
STILSensors.dll calls DLL_CHR.dll.
When running from source, you can view .NET assemblies in memory:
The puzzle here is to make the executable run without the prompt to point at STILSensors.dll.
I successfully fixed my project with a little help from an NI support engineer.
I moved the dll files from their usual folder onto the desktop, then deleted the constructor node and replaced with a new constructor node. I then saved the project, closed and quit labview.
When I opened the project, I was prompted for the missing DLL files, this showed me where the links were. I had 4 VIs linking to the STILSensors DLL.
When I opened each of the 4 VI’s I was asked to point to the missing STILSensors file, at this point I moved the DLL files back to the usual folder, I then re-made the constructor node link.
From there on I could build and not experience the prompt for STILSensors.dll.
The project needed the files removed, this forced it to look for the dll files again, at this point we could make the link good by pointing to the new STILSensors DLL file.
There’s a clue in the “<GAC>:\STILSensors” message.
Armed with the "GAC" clue, I then found this thread from 2009 with a similar issue.
https://forums.ni.com/t5/LabVIEW/NET-Issues-with-LabVIEW-8-5/m-p/607490
All that's left to do is to accept your solution as solution! That way it will be marked as solved, which is great for reference and prevents all of us from opening to see if we can help.
Kudo for posting the solution.
Search LabVIEW like a graph! The problem appeared to be solved but reappeared when creating a build after a few days more development.
I manged to solve this issue in the short-term by closing LabVIEW, renaming the dll to StilSensorsRenamed.dll. I then opened the project, opened-saved-closed all VIs with .NET nodes, added StilSensorsRenamed.dll to always included build properties, then created build.
I frequently fix small bugs and make updates which require a new build, I can’t have the overhead of this every time I make a change.
It appears from the forums that others have been experiencing similar issues since 2007. It appears to be related to the Global Assembly Cache (GAC) references within the VI.
I’m occasionally receiving a prompt to point to STILSensors.dll while editing source code.
It’s happened when editing a customized control .ctl file and while editing some VIs that have no .NET code inside.
After you navigate to STILSensors.dll, there is a button “Show Details”, when you click there, you receive another prompt to find STILSensors.dll.
After 2 or 3 times navigating to STILSensors.dll you can see the warnings list below.
Any idea why I get this prompt with apparently non-.NET VIs ? I can only think the controls are shared and somehow contain the same link.
The analysis from the OP about the problem is most likely not really complete.
The problem is not the GAC here, since the DLLs are not in the GAC but in an application private directory. And the DLLs that are the most likely the real culprit are not even .Net DLLs (libusb<xx>.dll) but rather standard DLLs and as such couldn't even be added to the GAC even if one would try to.
The real problem is here that Windows can not find those secondary DLLs like libusb0.dll, libusb)_x86.dll, libusbK.dll and possibly others, when LabVIEW asks it to load the STILSensors.dll. The apparent solution only worked by the weird fact that Windows saves the directory in which a file dialog was dismissed with the acknowledge button (OK, Save, Load or whatever is not the Cancel operation) as process current directory and that is also one of the directories that Windows will search when trying to load additional directories. But once you quite the application that is all gone and when you launch the app again, the current directory is initialized to the same directory that you started the executable from and the whole game will start again!
So what really happens is that LabVIEW asks Windows to load STILSensors.dll and Windows notices that this DLL also requires libusb0.dll and likely others too. Windows can't find it and tells LabVIEW, sorry can't load your STILSensors.dll. LabVIEW then prompts you to located that DLL which you do. Secretly Windows also changes the current directory for the current process to that directory. LabVIEW asks Windows now to load the DLL from the "new" path (which is the same it asked Windows before to load). Windows tries to load it again, notices that it needs also to load libusb0.dll and tries that and magically it works since the current directory is one of the directories Windows looks for DLLs too (although that could be disabled and Microsoft actually recommends new applications to disable this for security reasons as it provides a means for code injection by rogue application).
The solution is to explicitly move those secondary dependencies that are nowhere referenced by LabVIEW directly but fully required for the DLL to be loadable, into the same directory as where your exe resides rather than the data subdirectory. This can be done by adding an additional Destination to the build specifications that points to the same directory as where the build executable is supposed to go and then assign these DLL files in the Source File Settings to this Destination location in the drop down box.
Alternatively if you don't have to many DLLs in your project you can also simply change the "Destination path" for the "Support Directory" to not use the extra "data" item so that all DLLs are placed in the executable main folder.
This way the secondary DLLs are all located in the process executable directory, which is always the first directory Windows will search for additional DLL dependencies when trying to load a DLL.
