{"id":2783,"date":"2009-12-07T08:05:00","date_gmt":"2009-12-07T08:05:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/visualstudio\/2009\/12\/07\/bootstrapping-of-vs-packages-and-vsix-extensions-in-vs2010\/"},"modified":"2019-02-14T15:42:03","modified_gmt":"2019-02-14T23:42:03","slug":"bootstrapping-of-vs-packages-and-vsix-extensions-in-vs2010","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/visualstudio\/bootstrapping-of-vs-packages-and-vsix-extensions-in-vs2010\/","title":{"rendered":"Bootstrapping of VS packages and VSIX extensions in VS2010"},"content":{"rendered":"

\"dmitry\"<\/a> Dmitry Goncharenko: <\/strong>Developer, Visual Studio Platform<\/p>\n

Short bio<\/b>: 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.<\/p>\n

Visual Studio 2010 uses two technologies to make it much simpler<\/i> to deploy VS extensions:<\/p>\n

    \n
  1. VS Packages don\u2019t need to write registration information directly to the registry. They can provide all their registration information in PkgDef<\/a> files, instead. <\/li>\n
  2. VSIX<\/a> is the new deployment model available for deploying VS 2010 extensions. It is fully integrated into the IDE and provides a simple model for publishing extensions to the Visual Studio Gallery<\/a>.<\/li>\n<\/ol>\n

    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.<\/p>\n

    The Visual Studio process is launched by executing devenv.exe<\/strong>, which is located in <VsInstallRootFolder>Common7IDE. 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<\/b> logic. [Note that Express VS SKUs are launched using different executables but internally they have a very similar logic to devenv.exe.]<\/p>\n

    PkgDef Management draws its initialization parameters from the file devenv.pkgdef<\/b>, which is located next to devenv.exe (also called the \u201cMaster PkgDef<\/b>\u201d). This file defines the locations where VS should be looking for other PkgDef files and installed VSIX extensions. <\/p>\n

    \"image\"<\/a> <\/p>\n

    Here is the content of a sample devenv.pkgdef file:<\/p>\n

    \"image\"<\/a> <\/p>\n

    The table below describes some variables that will typically be in the Master PkgDef file:<\/p>\n\n\n\n\n\n\n\n
    \n

    Variable<\/b><\/p>\n<\/td>\n

    		\n

    Description<\/b><\/p>\n<\/td>\n<\/tr>\n

    \n

    RegistryRoot<\/p>\n<\/td>\n

    		\n

    The root registry location under HKEY_CURRENT_USER where user settings and configuration cache are stored.<\/p>\n<\/td>\n<\/tr>\n

    \n

    PkgDefSearchPath<\/p>\n<\/td>\n

    		\n

    The list of folders where to search for PkgDef files. The list can also include specific PkgDef files.<\/p>\n<\/td>\n<\/tr>\n

    \n

    ApplicationExtensionsFolder<\/p>\n<\/td>\n

    		\n

    The root folder under which machine wide VSIXs are deployed.<\/p>\n<\/td>\n<\/tr>\n

    \n

    UserExtensionsRootFolder<\/p>\n<\/td>\n

    		\n

    The root folder under which user specific VSIXs are deployed.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    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 HKLMSOFTWAREMicrosoftVisualStudio10.0 (or HKLMWow6432NodeSoftwareMicrosoftVisualStudio10.0<\/a> on 64-bit OSs). The folders listed in the PkgDefSearchPath <\/b>are scanned recursively and PkgDef files found there are loaded. PkgDef Management then scans recursively starting from extension folders under UserExtensionsRootFolder <\/b>and loads only those PkgDef files that belong to extensions marked as \u201cEnabled\u201d in the Extension Manager<\/strong> dialog.<\/p>\n

    \"image\"<\/a> <\/p>\n

    Once all Visual Studio configuration data is loaded and merged, it is then cached under HKCUSoftwareMicrosoftVisualStudio10.0_Config registry root. Since this cache can be updated at any moment don\u2019t ever edit it<\/a>. If you need to modify the configuration data (for example to register your VS package) add a PkgDef file instead to your extension. [Don\u2019t ever hardcode VS registry paths into your code. Use ShellSettingsManager<\/a> class from Microsoft.VisualStudio.Shell.10.0.dll to work with VS settings and configuration data.]<\/p>\n

    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<\/a> service is responsible for managing VS message pump and it as well deserves its own blog post (or even few).<\/p>\n

    So, how does all this tie to the Extension Manager and VSIX extensions? At some point SVsExtensionManager<\/a> 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<\/strong> files. All found VSIX extensions under ApplicationExtensionsFolder become available to VS. <\/p>\n

    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 \u201cper user\u201d folders are only loaded if the following criteria (as of the Beta 2 release) are met:<\/p>\n