Pkgdef and the Experimental Instance in VS 2010

***Disclaimer: This information is about Visual Studio 2010 only. The following may not be accurate for future releases.***

One of the new features we introduced with the Visual Studio 2008 Isolated Shell was the concept of a pkgdef file. Pkgdef is essentially a REG file with tokenization. For example, you could put $RootFolder$ in your pkgdef file to refer to the root directory of your isolated shell application. At runtime, these files are consumed by the VS Isolated Shell runtime and merged into the registry (with the tokens replaced by literal values). The registry merely acts as a cache of the information in your pkgdef files.

In Visual Studio 2010, the pkgdef model has been integrated into Visual Studio itself. As such, the manner in which your packages are built and (locally) deployed when developing with the Visual Studio 2010 SDK is significantly different (although the “F5 experience” should be the same).

Visual Studio Startup / Pkgdef Merge

On the very first launch of Visual Studio, the first thing that needs to happen is merging the pkgdef files into the registry. You can think of the destination registry key where these go as merely a cache used for performance. The fact that it’s a registry key is somewhat of an implementation detail. Here’s a graphical view of what happens:


Note in the above diagram that the cache location is under HKEY_CURRENT_USER, and that the key name is 10.0_Config. If you view this key in regedit, you’ll notice a sibling key named simply “10.0”. This 10.0 key holds your per-user settings (things like your personal preferences for fonts, window position, and other options).

In comparison to Visual Studio 2008 and running with the /ranu switch, these 10.0 and 10.0_Config keys map to the UserSettings and Configuration keys under HKCU\Software\Microsoft\VisualStudio\9.0 respectively.

It is a completely safe operation to delete the HKCU\…\10.0_Config key since Visual Studio will re-create it on the next launch.

“Experimental Instance” Startup / Pkgdef Merge

A very similar process happens when you run “devenv /rootsuffix Exp”. Instead of merging the pkgdef information to “10.0_Config”, everything is merged to “10.0Exp_Config”:



What are the “Pkgdef Files on Disk” locations?

There is a file called “devenv.pkgdef” in your VS installation folder (under Common7\IDE) that defines where pkgdef files are picked up from. First, pkgdef files are picked up from a few sub-folders under Common7\IDE. Secondly, you’ll notice that we scan a folder called “$AppDataLocalFolder$\Extensions”. On my user account this maps to:


When running with “/rootsuffix Exp” this would be:


In order for a pkgdef flie in the per-user location to be picked up by VS, it must also be declared as owned by a VSIX-based extension and enabled in HKCU\Microsoft\VisualStudio\10.0\ExtensionManager\EnabledExtensions. When you build a VSPackage or MEF component from one of the project templates in the Visual Studio 2010 SDK, this is all happening for you during the build.

Comments (7)

  1. Jason Haley says:

    Interesting Finds: June 6, 2009

  2. Jon says:

    I understand devenv /setup is never needed at all now?

  3. Aaron (one of the developers on my team working on the SDK) just wrote a couple of great posts for folks

  4. Aaron Marten says:

    @Jon I think the only case where devenv /setup will still be needed is for creating the ProjectTemplateCache and ItemTemplateCache for templates installed to Common7IDE.


  5. Vic Vega says:

    Hi Aaron,

               Is it possible to register my package from a custom location like "C:MYProjectrsMyVSPaclkagebin"? Is is good to edit devenv.pkgdef file to add my custom location?

    Thanks for the blog. It is very useful and they have changed a lot in VS2010. IN VS2008, I used to registered always without RANU (in HKLM , using tools like VSRegex) , because I need it to be visible for multiple users.

    Thanks & Regards


  6. Aaron Marten says:

    Hi Vic,

    If you want to build and deploy a VSIX that will install to a global location, you should include an <AllUsers>true</AllUsers> element in your VSIXManifest's Header section. This link has some more details:…/ff363239.aspx

    You should definitely not be changing the devenv.exe.pkgdef file.

    Regards, Aaron

  7. Hi Aaron,

    I have the same problem was Vic. Our package has dependency with many ohter dll's/assemably, some are in the same solution where the 'package; is in, other are not. So if i build the package project, the package dll and direct referances dll's are copied to the .10.0Extensions folder… but if a now do a build of a other assembly.. thent his just goes to the debugbin fodler a speficied in the project file.. is does not 'automaticcaly' get copied to the .10.0Extensions folder..

    do we need custom build step on each project to copy its output to .10.0Extensions..

    is there any though giving on this?