Loading .Net Assemblies Dynamically

[Sreeranjani]

Hi All,

 

I have a set of .Net dlls, all of which have same properties and methods, Is it possible to load a DLL dynamically into .Net container based on some condition at run time.

 

Thanks,

Sree Ranjani

[Rolf Kalbermatter]

 

Hi All,

 

I have a set of .Net dlls, all of which have same properties and methods, Is it possible to load a DLL dynamically into .Net container based on some condition at run time.

 

Thanks,

Sree Ranjani

 

 

You could write for each its own VI library and then dynamically load whatever .Net DLL interface you want to have at the moment through VI server or even more elegantly LVOOP dynamic dispatch.

[Sreeranjani]

Thank you,

 

But my actual use case is a to develop a plugin based EXE and the plugins can be DLLs, even the customers can create plugins and can store it in a specified folder from where I have to load it dynamically, so it is difficult to create LabVIEW wrapper for each DLL.

[Rolf Kalbermatter]

Thank you,

 

But my actual use case is a to develop a plugin based EXE and the plugins can be DLLs, even the customers can create plugins and can store it in a specified folder from where I have to load it dynamically, so it is difficult to create LabVIEW wrapper for each DLL.

 

LabVIEW does not expose an interface that would allow to load .Net assemblies dynamically. It is actually even so that any .Net assembly that was at some point loaded, will be kept loaded which can be troublesome if you want to debug a self written assembly and try to replace the previous assembly with a new one without restarting LabVIEW.

Therefore your best bet is to create a .Net wrapper assembly that implements your plugin interface with one additional method Initialize() or similar that takes a path to the actual .Net assembly and object instantiation you want to use. Then load that assembly in that method and instantiate the object interface you want and store the object pointer in a private variable. All the other methods and property accessors of your wrapper simply forward their call to the actual implementation in the initialized assembly object.