DLLs and Builds

[Tim_S]

I figured I should share something that bit me for a while.

The problem I was having is I was building an executable, transferring the executable, et. al., to another machine and getting a file dialog showing up when the executable starts. This was not happening on the build machine, only the target machine.

I tracked this down to a copy of a DLL I was using was in the PATH environmental variable. The build didn't include the DLL in the support files until I removed the path from the environmental variable. (Note: Changes to the environmental variables don't take effect until you restart LabVIEW).

[crelf]

I'm a little confused: so there was a path to the DLL in your path envvar, and once you removed it from the path envvar LabVIEW found the original DLL somewhere else?

[Tim_S]

I'm a little confused: so there was a path to the DLL in your path envvar, and once you removed it from the path envvar LabVIEW found the original DLL somewhere else?

Yes, that is correct. I've been thinking on this and I believe it's a feature to avoid including DLLs in Windows system and system32 directories.

[Rolf Kalbermatter]

Yes, that is correct. I've been thinking on this and I believe it's a feature to avoid including DLLs in Windows system and system32 directories.

This is an area in LabVIEW where there have been subtle changes over the versions. But basically if you only enter the DLL name into the path then LabVIEW will call the LoadLibrary() function with just the DLL name, which will cause Windows to search in all standard locations for the DLL. LabVIEW will update the path constant with the entire path to the DLL that Windows has loaded the DLL from, but will remember to only use the DLL name itself even in the future. And it will also not include the DLL into any build if you go to build an executable, assuming that it is either a system DLL or one being installed by a seperate installer (which is usually the common way that you get the directory to the DLL path in the PATH environment variable).

If you however browse to the DLL or enter the enitere name directly, then LabVIEW will assume that the DLL is private to your application and also include it in any build. This can cause havoc for system DLLs, since kernel32.dll on your XP system is seldom the same on another users system which will cause troubles. Also since about Windows XP Windows will attempt to load explicitly loaded DLLs (LoadLibrary() calls with a full path, even though the same DLL is already in memory from a different path as this was required to support the SxS DLL loading, an attempt to alleviate DLL hell, but in my opinion just a way to cause more DLL hell) and that causes total havoc for many DLLs from the Windows system.

Personally I think LabVIEW should explicitedly avoid from including any DLL into a build, that resides in either the Windows or the system directory, even if the user entered a full path, but it is debatable if it is LabVIEW's job to worry about such things. I do think that the influence of initially entering just a DLL name in the Call Library Node versus the entire path, should be made visible somehow and also be better documented.

[asbo]

Personally I think LabVIEW should explicitedly avoid from including any DLL into a build, that resides in either the Windows or the system directory, even if the user entered a full path, but it is debatable if it is LabVIEW's job to worry about such things. I do think that the influence of initially entering just a DLL name in the Call Library Node versus the entire path, should be made visible somehow and also be better documented.

I agree. To me, calling a DLL through a CLN/ActiveX Automation/.NET should be treated the same as trying to read C:\foobar.txt - it's *not* LabVIEW's job to make sure it's there. I like the change in behavior LabVIEW's made wrt when you only use the DLL name. I use that paradigm to ensure that whereever my software is run is actually configured correctly. If LabVIEW goes and includes DLL in my build, not only is the principle violated, but it could break the DLL's functionality as well.

[Tim_S]

This is an area in LabVIEW where there have been subtle changes over the versions. <snip>

Good to know.

Personally I think LabVIEW should explicitedly avoid from including any DLL into a build, that resides in either the Windows or the system directory, even if the user entered a full path, but it is debatable if it is LabVIEW's job to worry about such things. I do think that the influence of initially entering just a DLL name in the Call Library Node versus the entire path, should be made visible somehow and also be better documented.

When isn't it the case something can be better documented?

[Rolf Kalbermatter]

When isn't it the case something can be better documented?

Well whenever the information that is available is enough for me to know what I need to do. Of course in some areas that may be quite different for me than for other people.

[mje]

I think it's quite well documented.

Although you can specify the shared library to call by name or by path, these techniques use different search algorithms for locating the shared library and have different ramifications on distributing the shared libraries with stand-alone applications. Ensure that you choose the proper technique for your use case. For example, always specify system shared libraries, such as kernel32.dll, by name.

Note the referenced link in the quote.

Also relevant is the KB article Configuring the CLFN, which describes using wildcards, and a few other nuggets.