LabVIEW
Specify or Set a .NET Assembly (DLL) Call or Search Path for a Built LabVIEW EXE (Executable)
Solved!
I'd give viSearchPath a try.
Add this to the .ini of the exe:
viSearchPath="<topvi>:\*;;c:\new path"
I'm not sure what the default tis for executables. In LabVIEW.exe, the default is:
viSearchPath="<topvi>:\*;<foundvi>:\;<vilib>:\*;<userlib>:\*;<instrlib>:\*;C:\Program Files (x86)\National Instruments\LabVIEW 2013\resource"
I honestly don't know if this search path is used for .NET dll's, but it's worth a shot.
Alternatively, see this thread about why it's not working out, and why it shouldn't, and some potential workarounds.
I guess for .NET there are ways to dynamically load assemblies in memory, so LabVIEW will find them. I'm not sure how complicated that would be, since the assemblies are probably loaded when the VI's are loaded. I guess it would require dynamically loading of all VI's that use assemblies, even if dynamically loading the assemblies is possible (my guess would be .NET reflector subsystem).
Search LabVIEW like a graph! Ah. I got the permalink, but forgot to copy the URL:
That is .NET reflection. Sorry about that.
.NET reflection is a .NET class browser. It can be used to inspect .NET classes as well. It can be used for instance to get methods from an assembly, and to get inputs\outputs from the methods. It's been a while, but I thing it will load assemblies from a path. Not sure how helpful it is, it will probably mostly consume your time.
Please note that the explanations in that thread are really about standard DLLs. .Net DLLs have different search paths (most of the locations for standard DLLs do simply not apply).
Basically .Net by default only searches in the application directory (where the executable that started the current process resides) and in the GAC (Global Assembly Cache). LabVIEW adds to this the path where the current LabVIEW project resides (and maybe the directory where the library file is if the VI referencing the .Net assembly is part of a library, but I haven't confirmed this last one).
In order to add a .Net assembly to the GAC it needs to be strongly named, meaning it needs to have also a full version number and all that.
The search paths for .Net can be modified by adding other paths to the current application domain, which LabVIEW does for VIs which are part of a LabVIEW project. Beyond that LabVIEW can't really start to guess what other directories might be useful candidates to add to the application domain for .Net.
You could try to add your own paths by using AppDomain.AppendPrivatePath but that has been obsoleted as it changes the probing path directly which could cause problems for already loaded assemblies that need to be resolved again for whatever reason to load additional resources and then .Net might end up finding a different version of the assembly first.
The recommended alternative AppDomainSetup.PrivateBinPath won't work as it only works for newly created app domains, but the app domain in which LabVIEW runs its .Net subsystem has been already created when the first .Net function in LabVIEW gets called.
The recommended way to extend search locations at runtime is to implement the AppDomain.AssemblyResolve event.
@rolfk wrote:The recommended alternative AppDomainSetup.PrivateBinPath won't work as it only works for newly created app domains, but the app domain in which LabVIEW runs its .Net subsystem has been already created when the first .Net function in LabVIEW gets called.
The recommended way to extend search locations at runtime is to implement the AppDomain.AssemblyResolve event.
Would that work in practice? AFAIK, LabVIEW tries to load the assemblies when the VI's are loaded. So would adding a path from within the application work? I'd say dynamic loading is needed to make this work? So the exe can set this path, and then the assemblies are loaded with this new path set. That could be inconvenient.
A loader VI\splash screen might work. It would set the path and then start the real main.
wiebe@CARYA wrote:
@rolfk wrote:The recommended alternative AppDomainSetup.PrivateBinPath won't work as it only works for newly created app domains, but the app domain in which LabVIEW runs its .Net subsystem has been already created when the first .Net function in LabVIEW gets called.
The recommended way to extend search locations at runtime is to implement the AppDomain.AssemblyResolve event.
Would that work in practice? AFAIK, LabVIEW tries to load the assemblies when the VI's are loaded. So would adding a path from within the application work? I'd say dynamic loading is needed to make this work? So the exe can set this path, and then the assemblies are loaded with this new path set. That could be inconvenient.
A loader VI\splash screen might work. It would set the path and then start the real main.
Actually if you change the search path through AppDomain.AppendPrivatePath, then yes you would have to first load the code that changes the search path and then after that the code that references those .Net assemblies.
But AppDomain.AssemblyResolve is an event that gets triggered everytime .Net needs to resolve an assembly. I'm not sure if this event is triggered before .Net searches it's standard paths or when it hasn't found an assembly in those standard paths, but it is dynamic at runtime. Of course you need to have some code that installs that event and that needs to be also run before you load the VIs that try to load any assemblies whose paths you might resolve yourself.
But .Net resolution happens when an object is first instantiated so it may be possible to load the main .Net assembly without the dependencies, depending how that assembly instantiates its internal objects that have those dependencies.
Unfortunately .Net is a 200 ton dinosaurus with an internal architecture that beats most other setups in complexity. Solving an assembly resolver with an INI token in such a beast is worse than trying to patch up a real dinosaurus with some bandaids 
Try to do dynamic module loading in Java, which .Net is in many ways largely based on in terms of concepts and ideas and you end up with a module resolver that can be more complex than the actual code in the modules.
