LabVIEW
dll Working folder
It’s not the “wrong” one. You are trying to use .Net libraries in the wrong way. Microsoft finally seems to have made work of further trying to isolate assemblies into their application/user specific jail and only allow “blessed” assemblies properly installed into the GAC to be referenced from a global location.
Or maybe your DLL does somehow “nasty” things that the .Net CLR prompts into isolating it in a jail and load from there.
The C++ library you mention makes me wonder if your assembly is in reality really a mixed mode .Net assembly using the obsolete CLI. Microsoft discontinued CLI years ago.
@Andrey_Dmitriev wrote:
And as far as I remember, LabVIEW specifically will also take a look into \data subfolder and into \Shared\LabVIEW Run-Time\<version> folder.
No, that is so not entirely correct. What the LabVIEW application builder will do, is first determining what a DLL is. There are at least three possibilities:
1)The DLL is located in the LabVIEW/resource directory -> this is a LabVIEW runtime provided DLL. Do NOT copy it into the application build and only store the DLL name itself in the compiled code.
2) The DLL name is specified with the full path in the Call Library Node -> This is a private DLL and needs to be copied into the application build. It is copied into the support folder, by default called "data" (but this name can be changed, or even moved to be the application directory itself). The compiled code contains a relative path from the application directory to the DLL, eg. .\data\<dllname>.dll
3) The DLL is only specified with the DLL name and no path -> The Call Library Node still shows the full path but it remembers that only the name was specified -> This DLL is considered a system DLL and is NOT copied into the application build. The compiled VI code also only uses the DLL name. It is VERY important to specify any Windows system DLL such as kernel32.dll, ntdll.dll and advapi32.dll in this way. Otherwise the application builder will consider the DLL as a private DLL and copy it into the application build and Windows absolutely does not like this. These DLLs can NOT be copied around as you like!
When the application is loaded, LabVIEW does interpret the stored name as follows:
if it is anything else than just the dll name itself look at the provided path
if the path is relative, prepend the application directory to it and try to load it
if success, we are done
we couldn't load the private dll for some reason so just take the name only and try the alternatives
prepend the runtime resource folder to the name and try again
if success, we are done
still no success!
try to load the DLL just by name and let Windows search for it and all its dependenies
if success, we are done
still not successful, throw the hands in the air and return an according DLL load error
