LabVIEW
Labview built executable locating DLL location at startup
@JETMike wrote:
Yes, this does work and does resolve the problem. However, I want all of the files and folders that are in the same level as ..\Support to be where they are. It really clutters up the main app path when I do this.
If you really want that you have to add that directory to the PATH environment variable or install the DLLs into the bitness specific Windows System directory.
There is a possibility to call the Windows API SetDllDirectory() to add an extra folder to the search paths but that has a number of consequences.
1) You need to call this functions at application startup before any of the affected DLLs is searched.This means:
2) Your application can’t directly reference any DLL that relies on such dependencies. Instead you need to create a startup VI stub that calls this WinAPI function to add this directory to the process search paths and only then dynamically launches your main VI that uses those DLLs.
2a) Alternatively you can change all Call Library Nodes to have the library name specified on the diagram and pass the relevant path from the diagram to them. This will move the loading of the DLL from load time of your application (before you are able to set the additional search path) to when that node is first called (which should be of course after you set the search path). Additional trouble of this is that since the Call Library Node now gets the library path at runtime the application builder can’t anymore detect the DLLs it will call and you have to add them as always included resources to your application build too.
A lot of trouble for a rather cosmetic problem! Are you really that much bothered by those extra DLLs next to your exe?
https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order
Just see that your problem is about .Net DLLs. When designing .Net they were briefly trying to use the same DLL search path vodoo as was used for standard DLLs. But then the security people pointed out that this is a major security nightmare as it allows quite easy dependency injection. As a consequence .Net DLLs are by default only loaded from the GAC or the process application directory. Anything else requires to create a custom ApplicationContext at startup of the application and adding the desired directories to that context and then use that context to initialize your main .Net thread..And you can’t really change that later on to prevent a rogue DLL trying to open backdoors.
