||Carlos J. Quintero (Microsoft MVP)
||Microsoft Visual Studio 2010
||Microsoft Visual Studio 2012
By default, Visual Studio packages are not loaded at startup, to avoid consuming memory and CPU. Instead, Visual Studio loads them when needed (delayed loading). This article explains how to load packages when the IDE starts if really needed.
With some Visual Studio extensions, such as add-ins, whether the add-in is loaded or not at startup is determined by two factors:
- The decision of the add-in developer, who can decide whether to load the add-in on startup or not in the LoadBehavior entry of the .AddIn file.
- The decision of the add-in user, who can override the developer's decision through the "Startup" checkbox in the Add-In Manager. Note: for add-ins installed for all users, she needs to be an administrator to change that checkbox (otherwise it is disabled).
Visual Studio packages behave differently in several aspects:
- The end user cannot override the developer's decision (at least, not without modifying directly some registry entries).
- The user interface (UI) of the package (menus, toolbars, buttons, etc.) can be shown when Visual Studio is loaded without the need to load the package (the UI is persisted when the package is registered). When something is needed from the package (for example when a command is executed, either with a keyboard binding or clicking a menu entry or button), the package is loaded by Visual Studio. Although add-ins can use also this "permanent UI" approach, most likely they create the UI each time that they are loaded ("temporary UI" approach).
- Packages can be loaded automatically not only when the IDE starts (even empty, with no solution loaded yet), but also when the IDE "enters" in some UI context (for example, when a solution is loaded, when the solution has a single project, etc.). In this regard, packages have more flexibility. Each UI context is identified by a Guid. You can get some well-known UI context Guids in the Microsoft.VisualStudio.Shell.<version>.0.dll assembly, Microsoft.VisualStudio.VSConstants.UICONTEXT class. For example:
If a package provides a user interface and it just needs to be loaded when a command is executed or UI item is clicked, then it doesn't need to be marked to autoload when the IDE starts or enters in some UI context. However, an scenario where a package must be auto loaded is when it provides a feature that needs to listen to events raised by Visual Studio to perform some action. It would be weird that the user needs to execute a command or click some button to load the package and then starts listening to such events.
Note: You can use the "Extension Analyzer" Microsoft utility of the Visual Studio Gallery to see which packages are actually loaded in Visual Studio.
Visual Studio uses the Windows registry to store which packages must autoload, and in which UI context. For that purpose, it uses the following registry key:
where <version> is:
- 10.0 for Visual Studio 2010
- 11.0 for Visual Studio 2012
Note: the HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\<version>_Config registry key is a kind of cache created by Visual Studio (not requiring admin rights to be created) that is the result of merging the HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\<version> registry key (Windows 32-bit) or HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\VisualStudio\<version> registry key (Windows 64-bit) and disk-based .pkgdef files, so do not modify it (it can be recreated by Visual Studio at any time).
Inside that "AutoLoadPackages" registry key there is a subkey with the Guid of each possible UIContext. And for each UIContext Guid, the (Default) value is the friendly name of the UIContext Guid and there is a name/value pair for each package that must autoload in that UIContext, where the Name is the Guid of the package (you can check the package descriptions in the HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\<version>_Config\Packages registry key.
So, the registration of a package that needs to autoload should write that information to the registry or to the .pkgdef file.
Using the Managed Package Framework (MPF) to develop packages, you can use one or more ProvideAutoLoad(<UIContextGuid>) attributes applied to the main package class (the one that inherits from Package):
|Language: C#|| Copy Code (IE only)|
public sealed class MyVSPackagePackage : Package
Notice that attributes can't receive a Guid type directly, only the Guid string, so the VSConstants.UICONTEXT class provides constants ending with "_string".
The ProvideAutoLoad attribute inherits from Microsoft.VisualStudio.Shell.RegistrationAttribute, which provides overridable methods named Register and Unregister. When the VS SDK utilities that register packages (regpkg.exe) or create .pkgdef files (CreatePkgDef.exe) are called (even behind the scenes from Visual Studio by MSBuild tasks that the VS SDK provides), they iterate the types of the assembly, locate the custom attributes that inherit from Microsoft.VisualStudio.Shell.RegistrationAttribute and call their Register or Unregister methods. The ProvideAutoLoad attribute uses those methods to write / delete in the AutoLoadPackages registry key or .pkdef file (this "context" where to write is actually passed to those methods).
Go back to the 'Resources for Visual Studio .NET extensibility' section for more articles like this