***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).
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.
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”:
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.