LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

.NET events labview 8.6

I am using LabVIEW 8.6 and C# (.NET 3.5). I use .NET events with LabVIEW. The way to do this has been described in the help of LabVIEW 8.6. I use callback VIs. It works properly. But I’ll get a problem if I change the version of the assembly (using an unmodified event data format). There is no chance to use the old callback VI with the new assembly. I have to create a new callback VI…

This is very inconvenient since I use a lot of .NET events, my LabVIEW program is ready, and I develop the assembly (often new versions). Is it really a matter of fact that I have to create always new callback VIs or is there any trick?

Callback VIs have to be reentrant. Is there any chance to debug .NET events at the LabVIEW side?

0 Kudos
Message 1 of 10
(4,757 Views)

What happens exactly when you try to use the old callback VI with the new version of the .net assembly?

 

Yes you can debug callback VIs but it is tricky. One way of viewing internal values is to create an indicator on the front panel of the calling VI that will hold the data of interest. Next pass a reference to that indicator into the callback VI and use property nodes to programatically set the indicator value.

 

Mike...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 2 of 10
(4,704 Views)

Mike

 

Sorry for the late answer.

 

If I replace an assembly by a new one (modified version number, but the same event data format like before), the wire between callback VI and the "Register Event Callback" will be broken. Normally I select the constructor of the used class and the broken wires are repaired. But this doesn't work in this case.

 

 

Debugging of a callback VI works well. This isn't an ideal solution but a very helpful one.

 

Thanks Uli

0 Kudos
Message 3 of 10
(4,656 Views)

Yes, we had a similar behaviour once before and it was solved by telling LabVIEW to accept assembly versions that differ from the cached version info stored inside the .NET nodes. To do so, you have to create or modify the labview.exe.config file in the LV application or VI directory with appropriate entries.

The whole thing is related to a .NET versioning behaviour by design, and is documented on the MSDN (Microsoft Developer Network) website pretty well. If you search the web or this forum for labview.exe.config, you'll find more info on this.

 

Cheers,

Hans

0 Kudos
Message 4 of 10
(4,638 Views)

Hans

 

thank you for your answer. I was looking for the solution in the web and this forum. But I havn't found the problem solving. I wonder if you could send me a link.

 

Thanks Uli

0 Kudos
Message 5 of 10
(4,613 Views)

Hi again,

 

I've just done some tests with a simple assembly (DLL) and manually/automatically increased version numbers, used by LV 8.6. Seems like our former problems are history: When loading the VI, LabVIEW shows a warning that the assembly version changed but uses the DLL anyway and the VI works properly. Hmm...

😐

 

To get you started with version redirecting nevertheless, here's how a sample LabVIEW.exe.config file could look, placed in the LabVIEW application directory:

 

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <dependentAssembly>
            <assemblyIdentity name="AssemblyName"
                              publicKeyToken="1234abcd5678efgh"
                              culture="neutral" />
            <bindingRedirect oldVersion="1.0.0.0"
                             newVersion="1.0.0.1"/>
         </dependentAssembly>
      </assemblyBinding>
   </runtime>
</configuration>

 

Replace AssemblyName with the file name of your DLL (without suffix) and insert the correct publicKeyToken. Note that assembly versioning does only work this way with so-called strong named = signed assemblies, this is where the public key token comes from.

The syntax is pretty obvious, I think, it tells LV to accept a new version 1.0.0.1 even if 1.0.0.0 is expected. Look at the MSDN documentation for more info.

 

Cheers,

Hans

Message 6 of 10
(4,588 Views)

The story continues and I've started a new thread on this, you may want to read.

It's getting exciting!

0 Kudos
Message 7 of 10
(4,573 Views)

Hi

This is an interesting issue. I’ll watch the discussion.

Thanks for your comments to assembly versions used by a LabVIEW application. This will help me to understand a little bit better …

But my specific problem occurs in callback VIs only. I’d like to know if you have a particular link to the MSDN regards a ‘callback assembly version’ problem.

Thanks

 

0 Kudos
Message 8 of 10
(4,554 Views)

I think the callback problems you experience actually are related to the described versioning issue, and it is a LabVIEW specific one. Or to make it more clear: your problems show a misbehaviour or misuse of LabVIEW and its NIs turn to give you information on this, it has not much to do with .NET itself. Therefore the MSDN (Microsoft Developer Network) .NET documentation won't give you much more information here, since it does not deal with 3rd party = National Instruments aspects.

Nevertheless, the MSDN is inevitable when it comes to.NET related development tasks since you have to understand both, Microsofts .NET framework and LabVIEWs .NET functions/behaviour to make a good job!

 

 

0 Kudos
Message 9 of 10
(4,547 Views)

I fully agree with you.

Thanks again

0 Kudos
Message 10 of 10
(4,526 Views)