Jump to content

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


Recommended Posts

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 by NateAtUT
Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.