LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Multiple .net assembly versions and LVOOP issue?

Solved!
Go to solution
Solution
Accepted by WavePacket

@WavePacket wrote:


I fear I've misled you. So far as I'm aware, the .net dll does not have inheritance within itself. My understanding right now is that the .net dll has multiple versions, but it's multiple versions of a single class.


Then why do you want to have them all on the same system? If they all export the same class interface with different version as implementation, you should only need one of them on any specific system.

 

If you want them all, or any of them, in parallel you have a plugin system and should provide a class factory implemented in .Net, not LabVIEW. That factory can be the the base class from which all other implementations inherit or a separate class that returns you a base class interface for the requested implementation. As far as LabVIEW is concerned you only have one (or possibly two) classes, the base class providing the interface, and the factory class. And you always call the base class from the view of LabVIEW. That the actual class is in terms of .Net a class inherited from the base class doesn't matter for LabVIEW.

 

.Net won't easily let you have two assemblies implementing the same class name loaded in the same process. And trying to compile an assembly containing two times the same class name, will not even compile! You need different class names if the classes are not using the same implementation.

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 11 of 13
(467 Views)

@rolfk wrote:

@WavePacket wrote:


I fear I've misled you. So far as I'm aware, the .net dll does not have inheritance within itself. My understanding right now is that the .net dll has multiple versions, but it's multiple versions of a single class.


Then why do you want to have them all on the same system? If they all export the same class interface with different version as implementation, you should only need one of them on any specific system.

 

...


Potentially I shouldn't - my idea was if I ever needed to test an old device then I could test it under the appropriate version of the .dll. Maybe it makes more sense to handle this via version control of the test software itself? Like, I just roll back the whole program to the older version. 


------------------------------------------------------------------------------------

Please join the conversation to keep LabVIEW relevant for future engineers. Price hikes plus SaaS model has many current engineers seriously concerned...

Read the Conversation Here, LabVIEW-subscription-model-for-2022
0 Kudos
Message 12 of 13
(460 Views)

@WavePacket wrote:


Potentially I shouldn't - my idea was if I ever needed to test an old device then I could test it under the appropriate version of the .dll. Maybe it makes more sense to handle this via version control of the test software itself? Like, I just roll back the whole program to the older version. 


Version control is always a good idea! 😁

 

But you don't necessarily need to fall back to the old application completely. If your .Net dll name stays the same and the class name stays the same too, as does the class interface, it should be also possibly to simply replace the DLL with the older version to achieve the old behaviour for this part. Of course you need to be careful here. Adding a new method or property to the class in a newer version and using that in LabVIEW will break this. Your old DLL class doesn't implement this method or property, so LabVIEW will not be able to find it in the old DLL and your entire app breaks!

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 13 of 13
(453 Views)