LabVIEW and .NET 2.0

As some of you may know, Microsoft has announced the final ship date for the whole .NET 2.0 kit (Visual Studio 2005, SQL Server 2005, etc) as November 7th. In addition, there have been some posts on devzone regarding LabVIEW hanging if the .NET 2.0 beta is installed. So, I thought I'd take a moment and cover the state of the union for LabVIEW and the next release of .NET.

LabVIEW 7.x

Unfortunately, as some people have discovered, LabVIEW 7 is not compatible with .NET 2.0. This has to do with the fact that Microsoft has completely redesigned the way the framework is installed (specifically the GAC) and this has broken the code that provides you with the list of installed assemblies. There is currently no workaround for this problem other than to not install .NET 2.0.

However, I'm working on a patch to LV 7.1.1 that'll fix this problem. If you need this patch when it becomes available, please let me know (either post a comment or shoot me an email to bloggingbrian@gmail.com). Once the patch is ready, it'll behave as described in Constellation below.

Note that this is a patch to LV 7.1.1 only (which is a free upgrade available to 7.1 users). If you have an earlier version you must first upgrade or wait for the Constellation release.

Constellation

As you might expect, supporting .NET 2.0 is a requirement for Constellation and so you can have either or both .NET 1.1 and 2.0 installed. However, this raises an interesting question of which one you get if both are installed. So, here you go...

LabVIEW uses the C++ .NET feature of IJW ("it just works" - we didn't come up with that, it's classic MS tech-marketing) to bring up the .NET runtime (a.k.a the CLR) and talk back and forth between the LabVIEW native code and the LabVIEW .NET code.

Because of that, the version of the CLR that executes under LV is always the most recent CLR installed on your machine. You can read this article to get the complete details - see the Application Load Mechanisms and Possible Issues section. We are the third row in the table.

Picking the .NET Framework

In general, this should not matter to most LV .NET users. Running under the 2.0 CLR is pretty much like running under the 1.1 CLR so your application should not care. However, there are some breaking changes between 1.1 and 2.0 that could cause you some problems depending on what parts of .NET you are using in your application. Again, the article goes into the full details on that.

So, what happens if you absolutely need to run with the 1.1 CLR? Well, Microsoft has provided a configuration setting that forces a native application like LabVIEW to load a specified version of the CLR. For the LV development environment, you need to create a file called LabVIEW.exe.config (capitalization is optional) in the same directory as the EXE itself. Put the following into the file:

<configuration>
   <startup>
      <requiredRuntime version="v1.1.4322"/>
   </startup>
</configuration>

Now LabVIEW is going to run with the 1.1 version of .NET even if .NET 2.0 is installed. Obviously, you'd better have installed 1.1  :)

What about built applications? The same general rule applies - you need the requiredRuntime key put into your application's configuration file. See this previous post about how to create .NET configuration files for your built application.

What if your built component is a DLL instead of an EXE? Well, that gets a bit more complicated. The short answer is that the EXE that is loading your DLL must have the above configuration file.

The longer answer: The requiredRuntime key must be loaded before the CLR version is picked. Unfortunately, the DLL's configuration file isn't processed until after the CLR is loaded. This is because LV puts the configuration file into the AppDomain for you - .NET doesn't support DLL-level config files. But by this point the CLR is already up and running so....

Longer answer addendum: Another point to consider is that the CLR is loaded by the first part of any application to request .NET - you only get one CLR per process. Therefore, you could consider two LV DLLs, one that wants 1.1 and one that wants 2.0. Well, that's going to be a problem if the DLL configuration file picked the CLR. Which CLR you got would depend on the load order. Therefore, the application is always the one that picks the CLR version.

Again - this is only a problem IF you care which version of the CLR is loaded. Almost every application out there should not care. Almost... :)

Comments

[Greg]

Just to add to your post about forcing the version of the CLR - if you have both VS 2003 and VS 2005 installed, if you want to debug any VS 2003 CLR 1.1 apps that are called via COM Interop from a non .NET executable from VS 2003, you HAVE to have a .config file to force the CLR. Otherwise what happens is that when the interop layer kicks in, the subsystem automatically loads CLR 2.0, which VS 2003 can't cope with - it may crash or it may just shut the app down and drop back to the IDE! The .config file has to be in the same directory as the non .NET exe and has to be named the same way as the exe, e.g. hostprocess.exe.config.

[Sebastian Dau]

I could not make my LabVIEW 7.1.1 apps run with .NET 1.1 exclusively.
When I try to debug a .NET assembly called by LabVIEW, I can see in the output that labview loads .NET 2.0 core libs.
In adition it causes my cryptography assembly to throw an exeption out of an object that does not even exist in .NET 1.1 but in 2.0.

Any suggestions on how to overcome this problems?

[Brian Tyler]

I just retested it on 7.1.1f2 and the config file listed worked as expected. Are you talking about a built EXE from LV, or running the VI in the LV IDE? If this is a built application, remember that you need to change the name of the file to be your EXE (such as myapp.exe.config).

[tst]

Brian wrote that "Unfortunately, as some people have discovered, LabVIEW 7 is not compatible with .NET 2.0. This has to do with the fact that Microsoft has completely redesigned the way the framework is installed (specifically the GAC) and this has broken the code that provides you with the list of installed assemblies. There is currently no workaround for this problem other than to not install .NET 2.0."

I have a story.

A company came to us. They do some LV work, but mostly they develop in other languages and they wanted us to do some integration between their .Net DLL and their current LV program. I started reading the requirements and immediately said "You have LV 7.0 and .Net 2.0. Did you test this? I seem to remember reading that LV 7 does not support .Net 2.0". They said that they tested it and it works and so we moved forward.

So I started working on this and, lo and behold, I get 1172 errors. I looked around and found that I need to register the DLLs with LV and that the VI needs to be in the same folder as the DLL. In short, I did that with the DLL and I registered the .Net 2.0 System.Data assembly as well (which I used to cast to a DataTable object) and it seems to work fine.

So, what gives? I have zero .Net experience so far, but that definitely seems to me to be working (Even the system.data assembly which is located in the windows directory).
What are the issues in using .Net 2.0 with LV 7.0?

[Brian Tyler]

That is partly my fault for saying LV 7, using the general term for 7.x. The 7.1 release specifically hangs when you drop a constructor node or do any other action that brings up a list of assemblies.

In 7.0, you don't get the hang, but we aren't reporting the version information correctly (notice that you don't see System(2.0.0.0) in the list). In general, 7.0 seems to work with .NET 2.0, but I haven't done extensive testing with it.

Sorry for the confusion.

[Raveendra Jayakody]

I have LabView 7.1 installed on .net 2.0.
I would like to recieve the Patch for working with 2.0.
Thanks
Raveendra