LabVIEW
dll Working folder
LabVIEW changes nothing on those search paths (other than adding the project directory itself to the search paths for .Net assemblies when a VI is started from inside a project). Everything else is simple Windows search path handling and there is a significant difference between .Net assembly DLLs and classic DLLs.
For .Net assemblies only the executable directory and the GAC are normally searched by .Net. As mentioned for VIs executed from within a project, LabVIEW adds the project directory to the according AppContext. You can also add a manifest file to your executable to add additional paths, but .Net is very finicky about what it allows. It only really will let you choose directories that are located underneath the directory where your executable is located. This is for safety reason as .Net wants to prevent the possibility that random (potentially rogue assemblies) can be injected into a process by adding out of tree dependencies.
For classic DLLs things are a bit more involved. Here Windows will search for legacy reasons several other locations too, and an application has pretty much no way of changing anything here (Well it can add extra directories to search since Windows 8, but the relevant code in LabVIEW was originally done in Windows 3.1 and I doubt very much that there was a lot changed since. And no there is not a lot to change there, adding random other directories to the search path is something Microsoft discourages strongly as every new location is an additional security risk for code injection attacks). Basically for classic DLLs these directories are searched, and depending on some registry settings and other policy settings in a slightly different order:
- if already in memory with the same name, independent of the actual path, and it is not a SxS DLL, simply use that one
- search the directory in which the executable resides that started the current process
- search the System directory
- search the Windows directory
- search the current directory (this is rubbish and can be disabled by certain policies as it has ABSOLUTELY no place in a multitasking GUI application)
- search in every directory listed in the PATH environment variable (don't you like these DOS hacks??)
I suspect you mean the current directory when you talk about the working folder. This only works for classic DLLs, .Net rightly has almost completely abandoned the DOS concept of current directory. And it is total rubbish to use for a lot of reasons. First this is a process wide global variable. Your LabVIEW applications current directory is not the same as the Explorer one, or Outlook or whatever other application you have. It is initialized to the same directory as what the executable is located on startup, unless the process creator choose to set a different default directory in the CreateProcess() call. Second it can be randomly changed with explicit API calls by any code in your process. In addition the Windows file dialog will "helpfully" change it to whatever directory it was in if the user dismisses the file selection dialog to select a directory or file!
And there is absolutely no way to safely try to verify that the path is correct and set it differently if it is not, as there is always a window of opportunity for someone (including the file selection dialog) to change it back to whatever between setting it to correct it and hoping to use it when you do something that uses this current directory.
The directory a DLL is located in has specifically no special meaning in Windows, unless it is one of the listed directories above. So you can NOT simply put all DLLs in a random directory and hope that one of them will magically resolve to the others if they are dependencies. If you want to do that, the DLL programmer has to explicitly program that, by determining the full path to the current DLL, strip the DLL name and add the new name to that path and then try to load the DLL dynamically himself. Nothing in Windows DLL default handling will do that on its own!
Most likely, .Net does not like rogue directories scattered throughout your system and decided to copy the assembly into a private jail to prevent someone else from tinkering with it. UWP (which is entirely based on .Net) does not even allow out of jail directory access without explicit grant to such a directory. Every application is contained in its own private jail safe and only has access to that and its sub-directory and some system resources such as the UWP API. Everything else needs to be specifically granted by the user such as access to Documents, or Photos or similar.
It would seem that .Net considers some C:/Automation/ folder as highly unsafe and simply refuses to load the assembly from there directly, copying it instead into a private user folder and redirecting the load from there. Of course it does not know about the other dependencies that your assembly has as they are most likely interfaced through dynamic loading of some sort so .Net can not determine that they are needed and won't copy them along.
You have most likely only two options, either move all the DLLs into your actual project folder and reference them from there, or add them to the GAC. The later will however require that they are strongly named and signed.
.Net assemblies may seem like the holy grail for interfacing to external code. Easy to interface too because of the build in type library (if it is made correct). However, Microsoft really is trying to thighten security on .Net and discontinuing many rather loose practices since .Net 4.x. And they will push more and more to go UWP all the way, where .Net is the only API that is not only allowed to be called but even the only one really present.
