LabView-built .dll which makes calls to a .NET assembly

[NateAtUT]

Hello, 

 

I have a .NET/C# library which was written by a 3rd party.  Calling methods in it works perfectly from the LabView development environment (2013, 32bit) when using the .NET constructor and Invoke Nodes.

 

Calling methods in the .NET library also works perfectly when I build my LabView program into an executable and run it without the development environment.

 

HOWEVER, when I build the LabView program's functionality into a .dll instead, and then call functions in this Labview-built .dll via a CLFN instance in a higher-level VI, the underlying functionality of the .NET library doesn't work and the development environment subsequently hard-crashes and must be restarted.  ARGH!!

 

Any thoughts why this might be happening?  I've had no problems calling non-LabView C++ .dlls inside of LabView .dlls, but calling C# .dlls inside of LabView .dlls appears to be a no-go for me right now.  

 

Am I missing a compiler setting or is this basic paradigm just not possible? Or is it a known bug with LabView.  

 

Thanks,

Nate

Edited December 5, 2014 by NateAtUT

[Rolf Kalbermatter]

Hello, 

 

I have a .NET/C# library which was written by a 3rd party.  Calling methods in it works perfectly from the LabView development environment (2013, 32bit) when using the .NET constructor and Invoke Nodes.

 

Calling methods in the .NET library also works perfectly when I build my LabView program into an executable and run it without the development environment.

 

HOWEVER, when I build the LabView program's functionality into a .dll instead, and then call functions in this Labview-built .dll via a CLFN instance in a higher-level VI, the underlying functionality of the .NET library doesn't work and the development environment subsequently hard-crashes and must be restarted.  ARGH!!

 

Any thoughts why this might be happening?  I've had no problems calling non-LabView C++ .dlls inside of LabView .dlls, but calling C# .dlls inside of LabView .dlls appears to be a no-go for me right now.  

 

Am I missing a compiler setting or is this basic paradigm just not possible? Or is it a known bug with LabView.  

 

Thanks,

Nate

 

Where did you install the .Net DLL to? Your calling process knows nothing about the secondary .Net DLL at all. It just tells Windows to load that primary DLL and lets Windows and .Net find out about how to handle the rest. However Windows will only search in very specific and well known locations for secondary dependencies. In the case of .Net DLLs the only locations that are always guaranteed to be found are the GAC and the directory in which the executable file for the process is located (e.g. C:\<Program Files>\National Instruments\<your LabVIEW version> for the LabVIEW IDE and for build applications the directory from which you started your app). 

 

Anything else is bound to cause all kinds of weird problems unless you know what you are doing and tell .Net explicitly where to find your assemblies otherwise. This requires calling various .Net API calls directly and messing up here can make it impossible for your app to load .Net at all.