Although administrators don't typically use the Windows .NET Framework in scripts, they often need to deal with the .NET Framework as an installed runtime library used by applications. There's no officially endorsed way for Windows Script Host (WSH) to detect the .NET runtime library, but signs of the library's presence are evident in a typical system and you can use WSH to look for those signs.
The most useful technique I've found is to test the version number of the .NET core file, mscoree.dll. As far as I've been able to determine, the .NET installer always places this file in the System32 directory (even in legacy systems) and the file is always the DLL for the highest .NET runtime version installed.
The DotNetVersion function, which Listing 1 shows, retrieves the version number of mscoree.dll. For example, when I use the following code to call the DotNetVersion function
version = DotNetVersion
the version variable contains the string 2.0.31113.33. When the function doesn't find the file, it returns a version string of 0.0.0.0.
You can use the DotNetVersion function as a true/false test for .NET installation by extracting the major version number (i.e., the first number in the version string). A quick way to do this is to use the code
isInstalled = _
CBool(Split(version, _ ".")(0))
The isInstalled variable contains True when any version of mscoree.dll is installed or False when the file isn't found.
If you're trying to determine how high the level of .NET support is, you need to look at the build number (i.e., the third numeric field). For example, when I run the code
build = CLng(Split _
on my system, the build variable contains the number 31113. After you have the build number, you can easily compare it with a specific build number to determine whether you have the most current version available. (If you also need to obtain the .NET Framework service-pack level, see the article "Don't Expect to Get It Right the First Time," July 2005, InstantDoc ID 46509.)