views:

21161

answers:

10

A similar question was asked here, but was specific to .NET 3.5. Specifically, I'm looking for the following:

  1. What is the correct way to determine which .NET Framework versions and service packs are installed?
  2. Is there a list of registry keys that can be used?
  3. Are there any dependencies between Framework versions?
+2  A: 

Enumerate the subkeys of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP. Each subkey is a .Net version. It should have Install=1 value if it's present on the machine, an SP value that shows the service pack and an MSI=1 value if it was installed using an MSI. (.Net 2.0 on Vista doesn't have the last one for example, as it is part of the OS)

Franci Penov
I didn't find this key on my machine (XP Pro), but I did have this: HKLM\SOFTWARE\Microsoft\.NETFramework. However, the various values you describe don't exist for me.
Charlie
You should have this key if you have .NET 1.1 or later installed. The key you mentioned was only used for .NET 1.0.
Scott Dorman
+60  A: 

The registry is the "official" way to detect if a specific version of the Framework is installed, but which registry keys are needed change depending on the Framework version you are looking for.

Framework Version  Registry Key
------------------------------------------------------------------------------------------
1.0                HKLM\Software\Microsoft\.NETFramework\Policy\v1.0\3705 
1.1                HKLM\Software\Microsoft\NET Framework Setup\NDP\v1.1.4322\Install 
2.0                HKLM\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727\Install 
3.0                HKLM\Software\Microsoft\NET Framework Setup\NDP\v3.0\Setup\InstallSuccess 
3.5                HKLM\Software\Microsoft\NET Framework Setup\NDP\v3.5\Install 
4.0 Client Profile HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Client\Install
4.0 Full Profile   HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Full\Install

The value is also different. For .NET 1.0, the value is a String value; all others use a DWORD.

Determining the service pack level follows a similar pattern:

Framework Version  Registry Key
------------------------------------------------------------------------------------------
1.0                HKLM\Software\Microsoft\Active Setup\Installed Components\{78705f0d-e8db-4b2d-8193-982bdda15ecd}\Version 
1.0[1]             HKLM\Software\Microsoft\Active Setup\Installed Components\{FDC11A6F-17D1-48f9-9EA3-9051954BAA24}\Version 
1.1                HKLM\Software\Microsoft\NET Framework Setup\NDP\v1.1.4322\SP 
2.0                HKLM\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727\SP 
3.0                HKLM\Software\Microsoft\NET Framework Setup\NDP\v3.0\SP 
3.5                HKLM\Software\Microsoft\NET Framework Setup\NDP\v3.5\SP 
4.0 Client Profile HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Client\Servicing
4.0 Full Profile   HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Full\Servicing

[1] Windows Media Center or Windows XP Tablet Edition

As you can see, determining the SP level for .NET 1.0 changes if you are running on Windows Media Center or Windows XP Tablet Edition. Again, .NET 1.0 uses a string value while all of the others use a DWORD.

For .NET 1.0 the string value at either of these keys has a format of #,#,####,#. The last # is the Service Pack level.

While I didn't explicitly ask for this, if you want to know the exact version number of the Framework you would use these registry keys:

Framework Version  Registry Key
------------------------------------------------------------------------------------------
1.0                HKLM\Software\Microsoft\Active Setup\Installed Components\{78705f0d-e8db-4b2d-8193-982bdda15ecd}\Version 
1.0[1]             HKLM\Software\Microsoft\Active Setup\Installed Components\{FDC11A6F-17D1-48f9-9EA3-9051954BAA24}\Version 
1.1                HKLM\Software\Microsoft\NET Framework Setup\NDP\v1.1.4322 
2.0[2]             HKLM\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727\Version 
2.0[3]             HKLM\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727\Increment
3.0                HKLM\Software\Microsoft\NET Framework Setup\NDP\v3.0\Version 
3.5                HKLM\Software\Microsoft\NET Framework Setup\NDP\v3.5\Version 
4.0 Client Profile HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Version 
4.0 Full Profile   HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Version 

[1] Windows Media Center or Windows XP Tablet Edition
[2] .NET 2.0 SP1
[3] .NET 2.0 Original Release (RTM)

Again, .NET 1.0 uses a string value while all of the others use a DWORD.

For .NET 1.0 the string value at either of these keys has a format of #,#,####,#. The #,#,#### portion of the string is the Framework version.

For .NET 1.1, we use the name of the registry key itself, which represents the version number.

Finally, if you look at dependencies, .NET 3.0 adds additional functionality to .NET 2.0 so both .NET 2.0 and .NET 3.0 must both evaulate as being installed to correctly say that .NET 3.0 is installed. Likewise, .NET 3.5 adds additional functionality to .NET 2.0 and .NET 3.0, so .NET 2.0, .NET 3.0, and .NET 3. should all evaluate to being installed to correctly say that .NET 3.5 is installed.

.NET 4.0 installs a new version of the CLR (CLR version 4.0) which can run side-by-side with CLR 2.0.

Scott Dorman
This doesn't appear to work for .NET 1.1 under Vista x64. No v1.1.x keys are in any of the possible places. Ideas?
Chris Hynes
The keys for .NET 4.0 are not quite correct. I'm seeing these keys:HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Client\InstallHKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Full\InstallThe v4.0 folder only has one key, (Default) with a value of deprecated.
RandomEngy
@RandomEngy: You're correct. The registry keys should have been "v4" not "v4.0". I corrected the post.
Scott Dorman
Minor typo: 4.0 Full Profile HKLM\Softwaer\Microsoft\NET Framework Setup\NDP\v4\Full\ServicingI copied it and had some issues! Software has a typo on this key.
Nate Zaugg
+1  A: 

Using the Signum.Utilities library from SignumFramework (wich you can use stand-alone), you can get it nicely and without dealing with the registry by yourself:

 AboutTools.FrameworkVersions().ToConsole();
//Writes in my machine:
//v2.0.50727 SP2
//v3.0 SP2
//v3.5 SP1
mapache
Looking at the code for this method, it's not very complete as far as what registry keys it uses and will miss .NET 1.0 completely and doesn't distinguish between .NET 2.0 (RTM) and .NET 2.0 SP1. It also doesn't take into account the dependencies between framework versions.
Scott Dorman
You're right, it'll be upgraded in the next release.
mapache
Not a good solution. There's no good reason to download an entire library just to get the .NET version when you can do the same work yourself in about 3 lines of code. As a programmer, you SHOULD be able to "deal with the registry yourself."
DannySmurf
@DannySmurf I don't agree. When .NET 3.0 was introduced MS should have wrapped this in a .NET API (as soon as we had than one layer of FX on the same CLR). I'd rather have my application use a utility library, then when 4.1, 6.1, 7.100 arrives, I can just update the library and a config entry for which layer of .NET my app requires. Of course this argument doesn't hold water if none of the libraries work.
crtracy
A: 

Well anyway the Signum.Utilities methods are still an interesting way.

+1  A: 

You can also detect the version and service pack installed, based on Mscorlib.dll file version.

http://msdn.microsoft.com/en-us/kb/kb00318785.aspx

Priyatna Harun
+2  A: 

The Framework 4 beta installs to a differing registry key.

using System;
using System.Collections.ObjectModel;
using Microsoft.Win32;

class Program
{
    static void Main(string[] args)
    {
        foreach(Version ver in InstalledDotNetVersions())
            Console.WriteLine(ver);

        Console.ReadKey();
    }


    public static Collection<Version> InstalledDotNetVersions()
    {
        Collection<Version> versions = new Collection<Version>();
        RegistryKey NDPKey = Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\NET Framework Setup\NDP", true);
        if (NDPKey != null)
        {
            string[] subkeys = NDPKey.GetSubKeyNames();
            foreach (string subkey in subkeys)
            {
                GetDotNetVersion(NDPKey.OpenSubKey(subkey), subkey, versions);
                GetDotNetVersion(NDPKey.OpenSubKey(subkey).OpenSubKey("Client"), subkey, versions);
                GetDotNetVersion(NDPKey.OpenSubKey(subkey).OpenSubKey("Full"), subkey, versions);
            }
        }
        return versions;
    }

    private static void GetDotNetVersion(RegistryKey parentKey, string subVersionName, Collection<Version> versions)
    {
        if (parentKey != null)
        {
            string installed = Convert.ToString(parentKey.GetValue("Install"));
            if (installed == "1")
            {
                string version = Convert.ToString(parentKey.GetValue("Version"));
                if (string.IsNullOrEmpty(version))
                {
                    if (subVersionName.StartsWith("v"))
                        version = subVersionName.Substring(1);
                    else
                        version = subVersionName;
                }

                Version ver = new Version(version);

                if (!versions.Contains(ver))
                    versions.Add(ver);
            }
        }
    }
}
midspace
+3  A: 

Small correction for the .NET 4 keys. They are actually here for RTM:

HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\

Not in v4.0.

RandomEngy
Correct. I updated the accepted answer.
Scott Dorman
A: 

for 64 bit OS the path would be HKEY_LOCAL_MACHINE\SOFTWARE\wow6432Node\Microsoft\NET Framework Setup\NDP\

abhishek mehta
This is only "somewhat" true. The registry in 64-bit versions of Windows is divided into 32-bit and 64-bit keys (with many of the 32-bit keys having the same name as the 64-bit keys). The `Wow6432Node` registry key is part of the WOW64 registry reflector, which mirrors certain keys and values between the 64-bit and 32-bit registry views. There should be no need to access this key directly as the registry automatically handles the redirection and mirroring.
Scott Dorman
+1  A: 

There is an official Microsoft answer to this question at the following knowledge base article:

http://support.microsoft.com/kb/318785/en-us

Article ID: 318785 - Last Review: November 7, 2008 - Revision: 20.1 How to determine which versions of the .NET Framework are installed and whether service packs have been applied

Unfortunately, it doesn't appear to work, because the mscorlib.dll version in the 2.0 directory has a 2.0 version, and there is no mscorlib.dll version in either the 3.0 or 3.5 directories even though 3.5 SP1 is installed ... why would the official Microsoft answer be so misinformed?

anon
A: 

FWIW... here is another solution that seems to have been widely tested in the real world (but it is in C)

DJA
Yes, Aaron's solution is very complete and is the one you should use if you need to do this from an installation program. What he provides is the basis for my article on Code Project (http://www.codeproject.com/KB/dotnet/frameworkversiondetection.aspx), which is where this information originated.
Scott Dorman