Freigeben über

How to get a VS Package to load

  • Artikel

I was asked this question this morning and figured that I should share the answer more largely in case anyone else has this question.

What attribute do I need on my VSPackage so that my package will get loaded when it is needed? I see ProvideAutomationObject and ProvideLanguageCodeExpansion but I’m not sure what I would use for the parameters and I don’t see any explanation of them in the SDK doc or on the web. Any guidance you could provide would be appreciated.

Typically a package will be loaded when the system needs services or functionality the package provides. Packages declare their services and functionality in the registry.  The registry info allows VS to start up quickly and load only those packages which are necessary based on the context of the environment (user gestures, projects loaded, etc). For instance, declaring an automation object will cause your package to load when any addin, macro or other package tries to access your automation object. Using this type of mechanism is the preferred mechanism because it is simplest and is the most loosely coupled.

If you need to get your package to load based upon some other context (none of the services or functionality declarations work for your scenario), then you can use the auto-load behavior of VS to accomplish this.  Auto-loading occurs when a specific context becomes active in VS and you have declared this context to be associated with your package.  This is in the AutoLoadPackages registry key under the registry hive associated with VS.

For managed package development, one can use the ProvideAutoLoadAttribute class to declare that the package should load when a specific context is active in VS. This attribute takes a guid string identifying the context and when the context is active VS will load your package. The context guids are defined by VS and by packages (including 3rd parties) so there’s no complete list of all context guids, but the most common and useful guids are provided in the VS SDK. 

In native package development one can use the VsShell.IDL and VsShell80.IDL files to find the guids.

In managed package development one can use the following resources to get the guids:

The Microsoft.VisualStudio.Shell.Interop.8.0.dll assembly has the following string constants defined:

  • Microsoft.VisualStudio.Shell.Interop.UIContextGuids80.CodeWindow
  • Microsoft.VisualStudio.Shell.Interop.UIContextGuids80.DataSourceWindowAutoVisible
  • Microsoft.VisualStudio.Shell.Interop.UIContextGuids80.DataSourceWindowSupported
  • Microsoft.VisualStudio.Shell.Interop.UIContextGuids80.Debugging
  • Microsoft.VisualStudio.Shell.Interop.UIContextGuids80.DesignMode
  • Microsoft.VisualStudio.Shell.Interop.UIContextGuids80.Dragging
  • Microsoft.VisualStudio.Shell.Interop.UIContextGuids80.EmptySolution
  • Microsoft.VisualStudio.Shell.Interop.UIContextGuids80.FullScreenMode
  • Microsoft.VisualStudio.Shell.Interop.UIContextGuids80.NoSolution
  • Microsoft.VisualStudio.Shell.Interop.UIContextGuids80.NotBuildingAndNotDebugging
  • Microsoft.VisualStudio.Shell.Interop.UIContextGuids80.SolutionBuilding
  • Microsoft.VisualStudio.Shell.Interop.UIContextGuids80.SolutionExists
  • Microsoft.VisualStudio.Shell.Interop.UIContextGuids80.SolutionExistsAndNotBuildingAndNotDebugging
  • Microsoft.VisualStudio.Shell.Interop.UIContextGuids80.SolutionHasMultipleProjects
  • Microsoft.VisualStudio.Shell.Interop.UIContextGuids80.SolutionHasSingleProject
  • Microsoft.VisualStudio.Shell.Interop.UIContextGuids80.SolutionOrProjectUpgrading
  • Microsoft.VisualStudio.Shell.Interop.UIContextGuids80.ToolboxInitialized
  • Microsoft.VisualStudio.Shell.Interop.UIContextGuids80.WindowsFormsDesigner

There is also a set of managed GUID constants defined in Microsoft.VisualStudio.Shell.dll:

  • Microsoft.VisualStudio.VSConstants.UICONTEXT_CodeWindow
  • Microsoft.VisualStudio.VSConstants.UICONTEXT_Debugging
  • Microsoft.VisualStudio.VSConstants.UICONTEXT_DesignMode
  • Microsoft.VisualStudio.VSConstants.UICONTEXT_Dragging
  • Microsoft.VisualStudio.VSConstants.UICONTEXT_EmptySolution
  • Microsoft.VisualStudio.VSConstants.UICONTEXT_FullScreenMode
  • Microsoft.VisualStudio.VSConstants.UICONTEXT_NoSolution
  • Microsoft.VisualStudio.VSConstants.UICONTEXT_SolutionBuilding
  • Microsoft.VisualStudio.VSConstants.UICONTEXT_SolutionExists
  • Microsoft.VisualStudio.VSConstants.UICONTEXT_SolutionHasMultipleProjects
  • Microsoft.VisualStudio.VSConstants.UICONTEXT_SolutionHasSingleProject

(Note that the above list doesn't have all of the contexts - you can define your own from the strings above if you need a GUID type.)

As an example, SolutionExists is a context active when a solution exists.  A package associated with this context will be loaded when a solution exists (either created anew or opened). You can use any of these types of contexts to cause your package to load.

Furthermore the project system sets a context when the type of project it controls is active.  The same project guid that represents the project type is the context guid you could use to get your package to load when the specific kind of project you support is active.

Contexts are not all mutually exclusive.  Many can be active at the same time.  So for instance I can have the SolutionExists and DesignMode active at the same time.  Some are mutually exclusive.  For instance I cannot be in DesignMode and Debugging mode at the same time.

I hope this helps to get your packages to load when you need them to.

Allen

Comments