The official source of product insight from the Visual Studio Engineering Team
Dmitry Goncharenko: Developer, Visual Studio Platform
Short bio: Dmitry has been at Microsoft for about 10 years working on several areas of Visual Studio. For Visual Studio 2010, he helped to design and implement PkgDef management, VSIX technologies, and hosting of MEF components.
Visual Studio 2010 uses two technologies to make it much simpler to deploy VS extensions:
Given different (previously supported and new) types of extensions available in VS2010 it might be not clear how they are being discovered and bootstrapped by the IDE. This post is an attempt to shed some light onto this area of VS Platform.
The Visual Studio process is launched by executing devenv.exe, which is located in <VsInstallRootFolder>\Common7\IDE. After doing some critical steps like command line parsing and Watson integration initialization (the technology managing crash/hang dumps), devenv.exe initializes the PkgDef Management logic. [Note that Express VS SKUs are launched using different executables but internally they have a very similar logic to devenv.exe.]
PkgDef Management draws its initialization parameters from the file devenv.pkgdef, which is located next to devenv.exe (also called the “Master PkgDef”). This file defines the locations where VS should be looking for other PkgDef files and installed VSIX extensions.
Here is the content of a sample devenv.pkgdef file:
The table below describes some variables that will typically be in the Master PkgDef file:
The root registry location under HKEY_CURRENT_USER where user settings and configuration cache are stored.
The list of folders where to search for PkgDef files. The list can also include specific PkgDef files.
The root folder under which machine wide VSIXs are deployed.
The root folder under which user specific VSIXs are deployed.
The main job of PkgDef Management is to locate, load PkgDef files and merge them with the rest the configuration data that is located under HKLM\SOFTWARE\Microsoft\VisualStudio\10.0 (or HKLM\Wow6432Node\Software\Microsoft\VisualStudio\10.0 on 64-bit OSs). The folders listed in the PkgDefSearchPath are scanned recursively and PkgDef files found there are loaded. PkgDef Management then scans recursively starting from extension folders under UserExtensionsRootFolder and loads only those PkgDef files that belong to extensions marked as “Enabled” in the Extension Manager dialog.
Once all Visual Studio configuration data is loaded and merged, it is then cached under HKCU\Software\Microsoft\VisualStudio\10.0_Config registry root. Since this cache can be updated at any moment don’t ever edit it. If you need to modify the configuration data (for example to register your VS package) add a PkgDef file instead to your extension. [Don’t ever hardcode VS registry paths into your code. Use ShellSettingsManager class from Microsoft.VisualStudio.Shell.10.0.dll to work with VS settings and configuration data.]
Once the configuration data is ready, the rest of Visual Studio can use it to initialize its core services and build the UI (main frame, menus, command bars, tool windows, etc.) This step deserves its own discussion but it is beyond of the scope of this article. The very last step before the IDE starts receiving user input is to initialize the main message loop. SOleComponentManager service is responsible for managing VS message pump and it as well deserves its own blog post (or even few).
So, how does all this tie to the Extension Manager and VSIX extensions? At some point SVsExtensionManager service will be invoked (which depending on the scenario could be before or after VS became responsive). The service recursively scans below the ApplicationExtensionsFolder folder defined in the Master PkgDef file for extension.vsixmanifest files. All found VSIX extensions under ApplicationExtensionsFolder become available to VS.
UserExtensionsRootFolder in the Master PkgDef file specifies the path under which per-user VSIXs are installed (via the the Extension Manager dialog or by the Standalone VSIX installer). Extensions (VSIXs) installed into these “per user” folders are only loaded if the following criteria (as of the Beta 2 release) are met:
Only the VSIXs that are marked as “Enabled” in the Extension Manager dialog are considered by the service and made available to VS.
After a VSIX is enabled or disabled, VS might need to be restarted for this change to take an effect. This is true for VSIXs containing PkgDef files because, as it is described above, any changes to PkgDef files are processed only during the startup of VS.
Finally a short list of troubleshooting options for VS startup issues:
These are great technologies. I have one question Dmitry, can we use the PkgDef file to install an assembly into GAC? right now i'm looking at how i can use VSIX to install an Add-in. (i'm thinking to include one PkgDef in this VSIX package)
@Luxel No, you can't install assemblies to the GAC using a VSIX. If you need to go to the GAC, you'll have to use MSI or another installer technology.
@Marten Thank you for your answer. Right now i'm working on a SDK - which includes Project Templates, Item Templates, Wizards, Toolbox controls and an Add-in. However i'm unable to find a perfect way for deployment - VSIX doesn't support Add-in. I'm trying to avoid using MSI - so we can benefit from the VSIX/VSI technologies. Do you have any suggestion for such situation? Thanks!
In that case, you should stongly consider migrating your addin to a Visual Studio package and deploy your SDK via VSIX. All the functionality/services available to addins are also available to VSPackages.
I would like to use substitution values in the master pkgdef file (appname.pkgdef) from the package defined by the string "AppLocalizationPackage". Is it possible ?
So basically I can install my extensions by just copying a folder under .../IDE/Extensions whcih contains pkgdef and vsixmanifest right? That actually worked, but how do I uninstall it? Removing this folder doesn't remove it from extension managed but makes the record grayed out.
Is there a way to initializes SQL Server Management Studio and its menu system(like "devenv /setup /nosetupvstemplates")? or Is there a way to register VSPackage into SQL Server Management Studio?