When replacing a .NET assembly need to change LabVIEW code

[Dave_B]

I have a .dll that is a.NET assembly.  I use this .NET assembly in a vi.  When I receive an update of the assembly the labview vi stops working unitl I reconnect every create/invoke/property node in the code to the new assembly references.  The actual function calls etc. have NOT changed in the .NET assembly.  We did a test to just recompile the exact same code and replace the .NET assemblies that are referenced in LabVIEW with the newly compiled assemblies.  This caused an error message to be shown when opening the vi and required me to 'reconnect' every node in the code.  This will NOT work once the applications using the .NET assemblies grow to more than 4 or 5 nodes (right now I'm only testing the functionality).  Is this a known issue in the LabVIEW integration with .NET?  It doesn't seem to be working as it should...

[Odd_Modem]

To get the dot net to run you have the dll in the same folder as the vi, right? I think there are a bunch of other dlls that tell the editor the properties and methods. You might have left these in the dll project. Maybe try copying all the dlls from the compilation of the dot net into your LabVIEW folder and then see if it works over changes.

[Dave_B]

All files in the dll are located in the same directory as the vi.  What I think is happening is that the version number changes everytime the dll is recompiled and this number is what is referenced to in LabVIEW.  It shouldn't require reconnecting in the vi if the function calls haven't changed, this is very counterproductive!

[Odd_Modem]

Did you register the assembly under the tools menu, or did you just browse to the dll at the constructor?

[UlfN]

Hi,

I had the same problem as you with our .NET component. The problem is the .NET-version as you have guessed. We solved the problem by setting the version number to be fixed.

//Ulf

[Dave_B]

Thanks for that info!  How do I keep the version number constant, it is auto generated in visual studio?  Also, Have you spoken to anyone at National?  This is a major bug and a hinder to continued sw development in LabVIEW!!!!!!

[UlfN]

We are  also using Visual Studio(and Measurement Studio). I'm not sure were you can set it to be fixed. I havn't done it myself. Perhaps you can look it up in the Help-file?

I havn't told NI about this "feature". I wasn't sure if it was a bug or just me.

//Ulf

[UlfN]

We are  also using Visual Studio(and Measurement Studio). I'm not sure were you can set it to be fixed. I havn't done it myself. Perhaps you can look it up in the Help-file?

I havn't told NI about this "feature". I wasn't sure if it was a bug or just me.

//Ulf

[AnalogKid2DigitalMan]

This is 'normal' behavior in LV. It can be a real pain in the butt to manage. I have taken a route to minimize it's impact it by only having one instance of the constructor node in my entire application (keep reference open in top level vi and close it upon exit). Things may get better in version 8.

Maybe Brian Tyler (NI .Net guru) will chime in on this, he has a nose for any .Net related posts that come up.

[Dave_B]

Thanks for that!  It should help, so far I've just been making one .vi for testing of my communication dll and haven't created a class structure yet.  This will be good for putting the constructor node only in the create class vi.  To answer the other questions, I've gotten around it by setting the version to 1.0.0.0 in the assemblyinfo.cs file for the asembly.  This line looks like this now:

[assembly: AssemblyVersion("1.0.0.0")]

It used to look like this:

[assembly: AssemblyVersion("1.0.*")]

Which caused the compiler to change the version number constantly.  Again thanks for all of your answers! Hopefully NI will fix this!