.net assembly version hell

[smercurio_fc]

Is anybody else having problems with updating a private .NET assembly and then finding that all the LabVIEW code breaks, even though the functionality of the .NET assembly hasn't changed? Specifically, I'm finding that when I replace a private .NET assembly with an updated version (the version number gets automatically updated by Visual Studio), I find that the VIs that were accessing properties and methods from that .NET assembly now no longer can see the properties and methods. I have to go through each and every single VI and reselect the properties/methods, sometimes even going so far as creating new property nodes or method nodes. Further, if I look at the VI that has the constructor node, and I put the wiring tool on the output of the contructor node, and the Help window is open, the Help window indicates the version as being an earlier version, even though the contructor is selecting the most recent version. I find that I have to replace the constructor node with a new one and rewire. These problems existed with LabVIEW 7. I thought this was fixed in 8/8.2???

[tst]

I'm using 7.0 and I can't say I've seen this. In my case, the DLL usually has a program as well, so we uninstall and then install the new version. Since the VI is in another directory, I then copy the newly installed DLL to that directory.

Probably a stupid question, but did you register the .Net assembly in LV (Tools>>Advanced)?

[smercurio_fc]

The registration was removed in LabVIEW 8. In LabVIEW 8+ the relative path to the DLL is saved with the VI.

[tst]

OK.

I'm also guessing that if Brian will respond, he will want an example DLL.

[Lycangeek]

HA 🙂

You read my mind...can you post up two versions of the DLL with a VI that breaks? Are you seeing the same behavior in 8.2? 8.0?

[smercurio_fc]

I can't. They're proprietary. I'm going to have to see if I can come up with non-proprietary version or something else to try and replicate the behavior.