The strange case of the registry key HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0_Config\Projects\{C8D11400-126E-41CD-887F-60BD40844F9E}

Yesterday I returned from some days of vacations at Israel (Jerusalem and Tel-Aviv) and since the flight was being incredibly annoying and boring (after some hours in the airport and then a long delay before taking off) I decided to grab my laptop to work on a feature of the next version of my MZ-Tools add-in. This feature needs to know the guids of the project types supported by the Visual Studio IDE where MZ-Tools is loaded. I already wrote articles in the MZTools Articles Series about:

HOWTO: Get the project flavor (subtype) of a Visual Studio project from an add-in


INFO: List of known project type Guids

Visual Studio 2005 and 2008 used to store project type Guids in the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\<version>\Projects and I thought that the same applied to Visual Studio 2010. However, I noticed two strange issues:

  1. The project type guid {C8D11400-126E-41CD-887F-60BD40844F9E} (that belongs to Database projects of Visual Studio 2010) was not in the HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0\Projects registry key (or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\Projects if you are using a 64-bit Windows OS). Searching the registry I found that it was stored only in the HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0_Config\Projects registry key.
  2. Somehow, this code of my add-in was returning that project type guid even when it is not in the registry key (LocalMachine) that the code is querying:
Dim registryKey As RegistryKey

registryKey  = Microsoft.Win32.Registry.LocalMachine.OpenSubKey("Software\Microsoft\VisualStudio\10.0.Projects", False)


Needless to say, without Internet access and Google I depleted the battery of the laptop without finding the answers.

Today I found two posts of Aaron Marten about the HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0_Config registry key introduced by Visual Studio 2010. So, that registry key is built merging the HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0 registry key with Pkgdef files on disk. Since the {C8D11400-126E-41CD-887F-60BD40844F9E} value doesn’t appear in the HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0\Projects registry key, it could only come from a Pkgdef file, and certainly I found it: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Data\vspackage.pkgdef, which contains this fragment:


So, that explained issue #1, but what about the #2? How is that querying the subkeys of HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0\Projects returns the value {C8D11400-126E-41CD-887F-60BD40844F9E} that is only present in the HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0_Config\Projects registry key? Notice that this was a good thing for my purposes, but I didn’t have an explanation. So I used the Process Monitor utility to trace registry activity and I found that the code above was actually querying the HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0_Config\Projects registry key!!! That could only mean that somehow Visual Studio performs a registry redirection (not mentioned in the posts of Aaron), so that any query from the devenv.exe process (or its extensions!) to HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0 is redirected to HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0_Config. To confirm this, I executed that code from a Windows Forms application and not from a Visual Studio add-in, and certainly the {C8D11400-126E-41CD-887F-60BD40844F9E} value is not returned, because in this case no registry redirection is performed and the true HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0\Projects registry key is queried.