Missing/Can't Find .NET System.Environment Class

[Wiredup]

I'm using a .NET constructor, and cannot find the system.environment class. I'm trying to use the Environment.GetFolderPath method ( http://tinyurl.com/8bkk ). Anyone found this guy? Any help would be greatly appreciated. Perhaps my .NET is not installed properly? Thanks.

[Lycangeek]

He is hiding in the mscorlib assembly rather than the System assembly. However, as mscorlib does not live in the GAC, it doesn't show up by default when you are looking for it. You can find him in C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322.

Brian

[Wiredup]

Thanks for the response - unfortunately, I did look there (but perhaps did not see?).

I re-browsed to the path you provided (thank you). This then appears as the "mscorlib(1.0.5000.0)" under the "Assembly" heading in the "Select .NET Constructor" dialog after I press OK on the browse operation. I cannot find an "Environment" entry within the plain old "System" object, or the "System.various" objects below this entry.

Any more hints for the blind? Thanks for your help.

[Lycangeek]

It is kinda Zen...you can have it if you don't have it.

Okay, in english. The Environment class has no public constructor because all of its methods are static. Thus when you look for it in the constructor node, it isn't there because we filtered it out.

To use it, just drop a property node or a invoke node and right click on the input terminal where you normally would wire in a constructor output. One of the choices is "Select Class", then ".NET" then browse for it.

You are all set!

Brian

[Wiredup]

Zen is a wonderful thing. Found it. Many, many thanks to you for the help!

[NJKirchner]

When I bring up the list of available assemblies in LV 7.1 it does not show the newest versions of the assemblies. So I browse to the updated ones, and find the one I need, select it and go back to the browse window which still points to the old assembly.

The problem is that I need the method from the new assembly.

Sounds like you had the same problem, but what you were looking for was in both assemblies.

-Norm

[Lycangeek]

All, versioning in .NET. This topic is kind of like banging your head into the wall...

I've got some material on my blog regarding the issues of assembly versioning and LabVIEW - if you are interested in the various details you can check it out there.

The short answer is that LV 7.x relies on the ".NET Assembly References" to tell it where to find the DLLs when you are programming the VI. What it sounds like is that your reference was pointing to the v1 assembly. When you tried to browse to the 2.0 version, LV saw that it was the same name (say foo.dll) and simple reverted to the one it already had loaded. So you need to update your reference in the ".NET Assembly References" and restart LabVIEW (you need to restart because we've already loaded v1 into our reflection domain and .NET doesn't let you unload a single assembly).

HOWEVER

Due to the way the 7.x code works, you should keep all your assemblies either in the GAC or in the same directory as the VI. Failure to do this can result in runtime errors b/c it can't find the assembly (or binding to the wrong DLL if the older DLL is in the same directory as the VI). This is all based on the rules .NET has about finding assemblies (See my blog for the full details).

I'm going to stop there because I don't want to overload anyone. If you are interested in more, or have questions from my blog material, please let me know.