.NET contructor node

[Zuc_lab2]

Hi, 

is there a way to programmatically select the path (as an input) of the DLL selected in a constructore node? Or a solution where i allow the user to select the dll by means of a pop-up can be accepted. 

I have a dll that have been installed with different paths during the development and my VI have to interface with it.

Thank you for the help!

Best regards,

Zuc

[Kyle97330]

Traditional (non-.NET DLLs) had this option, but .NET DLLs do not, in LabVIEW.

Why do you need to do this?  Is it for using different bitnesses of the same DLL (32/64)?  Is this a DLL you or your company created, or is it a 3rd-party DLL you have no control over?

I can only think of two methods and neither one is easy.

Method one would be to create a PPL (.lvlibp) package for each different DLL, then load one or the other as plugins during run-time.  You would still need to know the path beforehand for each PPL.

Method two would be to dynamically load the DLLs using .NET calls.  .NET calls in LabVIEW use a part of .NET called "Reflection" which is what lets some .NET code load, analyze, and call functions on unknown DLLs during runtime.  The same function calls that do this for LabVIEW can be called by LabVIEW in theory, so you could do "Double reflection" and load the DLLs dynamically in that way.  This would mean you could use any path to a DLL, but would be a massive pain to implement.

[Zuc_lab2]

Hi  Kyle97330,

the fact is not only the bitness but different developers in my company have worked on the project so, not only the number of DLLs but also their location has changed and i want to find a way to group all the DLLs but if something missing, left the possibility to select the DLL in the right path (maybe someone has changed the DLLs locally and want to test them).

I don't completely get the method 2, do you have any link or material on which i can read about?

Thank you for the help,

best Regards,

Zuc

[Kyle97330]

You can start by loading the assembly in .NET using LabVIEW .NET nodes, like so:

That's a static invoke node, with the class, assembly, and namespace shown in the window.  It allows you to load any .NET DLL from a path on disk and, with the right follow-up calls, you can theoretically call constructors and other functions from it.

There will be ZERO guides on how to do this in LabVIEW, because it's kind of an insane proposition.  You will have to look up guides on how to use "Reflection" in .NET using C# or whatever, then apply those guides to LabVIEW on your own.

[Zuc_lab2]

Hi Kyle,

thank you for the idea, but i can extrac the reference of my class and methods, the VI remains broken:

So what do you connect to the reference in output from loadFrom?

Best Regards,

Zuc 

[Kyle97330]

I don't think you're understanding.  This is not something "easy".  This will actually be really hard.  You will not be able to just connect the output of that function to a wire and have it work just like normal .NET code in LabVIEW.

This is a link to that function in .NET:

https://learn.microsoft.com/en-us/dotnet/api/system.reflection.assembly.loadfrom?view=netframework-4...

One you have an assembly, you can run GetTypes on it.  Then, for each Type, you can run GetMethods, GetProperties, and GetConstructors.  Then you can manipulate those.  But every single manipulation you do will be dynamic, i.e. there will not be a property node for any of them that you can "pre-create" in LabVIEW to act like "normal" .NET code.

[rolfk]

There are two ways, to do that. All the way through reflection or a combination of reflection and LabVIEW scripting. None of them is easy at all and definitely going to take a huge effort.

LabVIEW factually uses that reflection interface itself to enumerate all the classes, methods, and properties and then populate the according nodes with that information. But the selection of what needs to be called happens then by the user. And at execution time LabVIEW uses the Dispatch interface to call those methods and properties.

All of that is available through .Net and can be called by any programmer, but it is rather involved. The first solution is to use reflection to enumerate everything, SOMEHOW decide what needs to be called and then use the .Net dispatch methods to execute the according methods and properties.

The other solution is to again do the enumerations, SOMEHOW decide what needs to be called and then use LabVIEW scripting to generate VIs that do the according thing.

Each of these is A LOT of work. And the very tricky part is the SOMEHOW in both of these. Each assembly is different, with different classes, methods and properties and different needs how they need to be tied together. Going from the WHAT IS AVAILABLE in an assembly to WHAT IS NEEDED to be called and in what way and order is the truly difficult part here. The rest is not easy but also not really rocket science once you have learned the principle, but it's a lot of work.