Jump to content

How to dynamically load and unload .NET DLLs?


Recommended Posts

Hello,

I am trying to find a way to dynamically load and possibly unload .NET DLLs in LabVIEW. This is easy to do when you can use the "Call Library Function Node" to call your DLL by specifying its path on the block diagram. However, it doesn't seem like there is an easy way to do that for .NET DLLs.

I use the .NET constructor node to create an instance of my .NET object which is my DLL, and I use property or invoke nodes to access my DLL methods. 

Does anyone know how this can be done? 

Thank you for your help!

 

Link to comment
42 minutes ago, Ben_V said:

Hello,

I am trying to find a way to dynamically load and possibly unload .NET DLLs in LabVIEW. This is easy to do when you can use the "Call Library Function Node" to call your DLL by specifying its path on the block diagram. However, it doesn't seem like there is an easy way to do that for .NET DLLs.

I use the .NET constructor node to create an instance of my .NET object which is my DLL, and I use property or invoke nodes to access my DLL methods. 

Does anyone know how this can be done? 

Thank you for your help!

Not directly. But I solved that in the past by creating VIs that called the .Net (or ActiveX) nodes and then calling those VIs dynamically through VI Server. A sort plugin system with the dynamic called VIs containing the .Net or ActiveX nodes.

Link to comment
15 hours ago, Ben_V said:

@Rolf Kalbermatter thank you for your answer. 

Is it possible to specify the path to the .NET DLL? The issue is that the .NET DLL location may change after I deploy it.

No it's not. A .Net DLL is not supposed to change location in build applications.

.Net itself only knows really two locations by default where it will search for assemblies:

- The directory in which the current executable file is located

- The GAC

Anything else is extra, such as an non-default AppDomain with its custom ApplicationBase.

LabVIEW adds to this the option to reference Assemblies by full path (which the application builder adjusts to the location you configured the assembly to be installed to) but that path is embedded in the compiled VI and not accessible just as you can't change the path of subVIs in a compiled executable either.

  • Like 1
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
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.