LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Multiple .NET dll versions

Highlighted

Hello all,

 

I'm trying to create a test executive to support many different robots that use the same .NET DLL, but use different versions of it. My thought was to use a case structure to determine which robot I was connected to and then load the appropriate vis and thus version from there. However, LabView loads the DLL into memory when you first open a sub vi and I cannot add the new sub-functions without Labview thinking I changed the directory path of the DLL. I renamed all the sub-functions so that they are unique by version, including the name of the DLL itself, but that doesn't work. Is there a way to load dynamic DLL versions in LabView? Is there a way to use vi servers to accomplish this so that I can at least create the infrastructure?

 

Thank you

0 Kudos
Message 1 of 7
(1,127 Views)
Highlighted

While .Net components are usually distributed in a file with a dll extension you should not talk about DLL in this context. There is .Net, Active X and function DLL interface and each of them is avery distinct species that only happen to be distributed in a file with a dll extension by some decision of Microsoft.

 

There is no way to dynamically link to .Net or Active X components. The way to do that would be to write individual VI (libraries) for each version of your .Net component and then load those VIs dynamically at the point you need them. But most likely you won't be able to load two different VIs using each a different version of the same .Net component at the same time. It all depends a bit if the .Net components are sttrongly named (something the developer of the component has to do and which requires among other things signing of the component).

 

You can dynamically load function DLLs in newer LabVIEW versions but that is irrelevant for .Net components. Also if you have multiple Call Library Nodes having loaded the same DLL you first have to make sure that at every place you have used such a Call Library Node to load a function from that DLL, you pass in an invalid library path to unload that function and DLL, before you can attempt to cause LabVIEW to load another version of the DLL with the same filename into a Call Library Node. Possible but pretty awkward and not very helpfull when you have multiple places that reference the same DLL. So even in this case the most simple solution is actually to write a VI library for each version of the DLL and load and unload those VIs dynamically.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 2 of 7
(1,099 Views)
Highlighted

Rolfk,

 

Thank you so much for your response. So, to expand on your point, I have created individual vi libraries for each version of the .NET dll component. How would I go about loading and unloading them dynamically?

 

Thanks again,

 

T

0 Kudos
Message 3 of 7
(1,084 Views)
Highlighted

Look at Open VI Reference, Call By Reference and/or Asynchronous Call By Reference.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 4 of 7
(1,082 Views)
Highlighted

Thank you much!

 

A couple of questions regarding these:

 

1. How does this affect execution time?

2. When using an installer, do the referenced vi get included as well?

 

 

Thanks again,

 

T

0 Kudos
Message 5 of 7
(1,080 Views)
Highlighted

As far as I have been able to determine, once LabVIEW loads a .NET dll into memory, it stays there until LabVIEW exits.  You cannot unload it and you cannot load a different version over it.  However, if a .NET assembly is not yet loaded, you can select which one to load. See attachment.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 6 of 7
(1,046 Views)
Highlighted

Hey Paul,

 

Thanks! Your solution would work if .NET dll all had the same functions and methods, so that the vis calling the functions would work accordingly. Unfortunately, they don't. I have created different sub vis for every version of the dll, so what I'm going to have to do is call those vis dynamically at run time. I've never done this before, so should be a learning experience. I'm sure I'll have many questions on that. BTW, nice work on the MCL, I've always stayed away from those because they seem like too much work.Smiley Happy

 

If you have any tips on opening/using vi references, I'm all ears.

 

Thanks again

0 Kudos
Message 7 of 7
(1,036 Views)