All Your RegKeys Are Belong To Us

I’ve been in many discussions lately with various folks about Visual Studio 2010 extensibility. Inevitably, someone suggests a solution to some problem involving changing/adding/deleting a registry key/value for an extension. If you need to do this, just remember this one rule:

Do not ever edit a key that ends in “_Config”


This key contains your user-specific settings and works the same as it has in prior VS releases. This could be things like pointers to your default project locations, window layout data, etc… In general it is OK to make tweaks to this key. The worst thing that could happen is that you end up corrupting your user settings. Deleting the key will cause the first-launch “Please choose a profile” dialog to come up the next time you launch Visual Studio.


If you examine the contents of this key, you’ll see that it contains the configuration data for VS 2010. This includes things like package registration, project system registration, editor factory registration, etc… You may also notice that the contents are very similar to HKLM\Software\Microsoft\VisualStudio\10.0.

You can think of the _Config key as a volatile cache of VS’s configuration data for a particular user. It is simply the combination of HKLM\Software\Microsoft\VisualStudio\10.0 and any pkgdef files coming from VS extensions (either from Common7\IDE\Extensions or %LocalAppData%\Microsoft\VisualStudio\10.0\Extensions).



(A previous post discussed how the Experimental Instance works.)

If you edit a key in 10.0_Config, Visual Studio will (quite possibly) delete it on startup.

If you need to change a value, always do one of the following:

  1. Edit the value under HKLM\Software\Microsoft\VisualStudio\10.0
  2. Edit (or add) a pkgdef file for the extension in question (For managed VSPackages, this is likely editing/adding a RegistrationAttribute in your code).
Comments (4)
  1. Nir says:

    Hi Aaron, thanks for this clarification, what is the best way to query value of an isolated VS2010 shell application?

    Is it by explicitly retreiving values for it’s isolated hive, or there is another more elegant way proggramatically?

  2. Julien Lebosquain says:

    Hello and thanks for the warning, I was struggling with these magical self-reappearing keys.

    However, how can I remove information for a specific instance? My problem is that I have ReSharper installed (in HKLM), but I don’t want it to be loaded for the experimental instance. First I was simply deleting the package from the 10.0Exp_Config but to no avail since the key is automatically recreated from HKLM. Deleting the package from HKLM is not an option since I want ReSharper to continue loading for the normal VS instance.

    I can’t seem to find a proper way to do this. Should I run a script that will delete/create the package key and then run devenv with the instance I want? It seems to defeat the purpose of the exp instance… Thanks for your answer!

  3. Aaron Marten says:

    @Nir : Do you mean from within the context of a running package or externally? If you are hosted in the shell app and have an IServiceProvider, you can use the new "SettingsStore" classes in Microsoft.VisualStudio.Shell.10 to read registry values.

  4. Aaron Marten says:

    @Julien: There is no way I know of to do this.

Comments are closed.

Skip to main content