Dotneteers.net
All for .net, .net for all!

VS 2010 Package Development – Chapter 1: Visual Studio Packages

I have spent a lot of time with preparing a book about Visual Studio Extensibility, focusing on Visual Studio Package Development. I have made proposals for several book publishers, but I did not manage to get a contract, most of them found such a book is not profitable. I decided to share the four chapters of the book that I’ve already written. They are the followings:

  • Chapter 1: Visual Studio Packages
  • Chapter 2: Commands, Menus and Toolbars
  • Chapter 3: Window Management and Tool Windows
  • Chapter 4: Services

I hope, you will find these chapters useful.


The majority of Visual Studio’s functions you use in your everyday work (such as programming languages, editors, designers and debuggers) are provided by Visual Studio Integration Packages, or shortly by packages. Some call them VSIP packages but the VSIP acronym is overloaded: while the first two letters means “Visual Studio” the last two may mean either “Integration Package” or “Industry Partner” and unfortunately both terms are frequently used. To avoid ambiguity hereinafter you’ll meet the term package or VSPackage.

Developing packages means you can extend Visual Studio on the same way as its developer team at Microsoft. Adding new functions through packages is actually programming a new part of Visual Studio just like if you were the member of the team. You can use the full power and integrate any functionality you miss from the IDE!

In this chapter you will create a very simple package called FirstLook to get a feeling that first steps are easy. Then you’ll learn the basic concepts behind packages and dive into the FirstLook project’s structure and source code to have a closer look at the implementation of those concepts. At the end of this chapter you’ll be familiar with the following:

  • Building a package with the VSPackage Wizard
  • The idea of a package
  • The on-demand package loading mechanism and the idea of package siting
  • Registration of packages and information stored in the registry
  • The Visual Studio Experimental Hive and using it for debugging packages
  • The package build process
  • Deploying VSPackages

This chapter will not teach you how to build a specific functionality into a package and does not cover the API used to develop packages. The focus is on understanding the concepts, architectural considerations behind VSPackages to let you take a look behind the scenes and get acquainted with package mechanisms. These concepts will be very useful when you are about creating your own packages.

Building a Simple Package

There are a few important concepts to understand if you want to develop a package. In order treat them in the right context you build a very simple functional package to touch the surface of those concepts and then jump into the details.

A Visual Studio package is a class library containing the types responsible for the package infrastructure and functionality. In order Visual Studio recognize the compiled class library as package, encapsulated types should have specific metadata information and some additional steps are required after compilation. So, even if you could start building a package from an empty class library, it is much easier to use the VSPackage Wizard installed with Visual Studio SDK.

Start a new project with the File|New|Project command. The IDE displays the New File dialog to select the desired project type. You can find the Visual Studio Integration Package project type under the Other Project Types category in the Extensibility folder as Figure 1 illustrates.

f0301

Figure 1: The New Project dialog with the Extensibility project types

Should you not find this project type or many other project types in the Extensibility folder means that Visual Studio SDK is not — or not properly — installed on your machine. Install it according to the setup notes in order to go on with building the package.

Give the FirstLook name to the package in order to be able to follow code details later in this chapter. Clicking the OK button starts the Visual Studio Integration Package Wizard (henceforward VSPackage Wizard is used, it is shorter) which welcomes you with the dialog in Figure 2.

f0302

Figure 2: The Welcome page of the VSPackage Wizard

Click the Next button to go on specifying the package parameters and you get to the Select a Programming Language page of the wizard as Figure 3 shows.

f0303

Figure 3: VSPackage Wizard lets you select the programming language

As it was mentioned earlier you create the code in C#. Packages are strongly named assemblies, so you need to sign the class library assembly with a key. For this project the wizard creates the signing key. Click Next and you get to the Basic VSPackage Information page as Figure 4 shows.

f0304

Figure 4: The wizard asks for the basic package information

The information you provide here will be used in the source code generated for the package and will be displayed in the Visual Studio About dialog. The Company name will be used in the namespace of generated types as well as VSPackage name which also names the class representing the package in code. VSPackage version is additional information to give a way for distinguishing separate package releases.

Text typed in the Detailed information field will be displayed in the About dialog and can supply the user with more information about what the package does.

When you click the Next button the wizard moves you to the VSPackage Options page — as can be seen in Figure 5 — to set a few more code generation options.

f0305

Figure 5: You can select a few code generation options

In this sample you are going to create only a menu command that pops up a message on the screen, so set the Menu Command option. Should you select the other two options the VSPackage Wizard would create some more code for a simple tool window or a rich text editor. Please, let those options remain unchecked. With the Next button the wizard goes to the page where we can specify a few details about the menu command to create. This page is shown in Figure 6.

f0306

Figure 6: Command options are specified here

The command will be added to the Tools menu of Visual Studio, in Command name you can specify the text to be displayed for the menu item. According to the internal command handling architecture each command has an identifier. The Command ID field supplies a name for this identifier and VSPackage Wizard will generate an ID value behind this name. With clicking Next the wizard moves to the Test Project Options page as shown in Figure 7.

f0307

Figure 7: VSPackage Wizard asks for test project options

The wizard can create unit test for the package which check if its functional units work properly. The wizard also can create an integration test project for you, in which packages are tested within the context of a Visual Studio instance.

For the sake of simplicity here you do not create any tests, so clear the options — by default both are checked. Now you have set all parameters the wizard uses to generate the package project, click on the Finish button.

In a few seconds the wizard generates the package project ready to build and run. Taste the pudding you have just cooked! With the Build ð Rebuild Solution function you can compile the package and carry out all other steps required to run the package with Visual Studio. So rebuild the project and start with Ctrl + F5 (Debug|Start Without Debugging).

You might be surprised as a new instance of Visual Studio is started with “Experimental Instance” in its window caption.

Note: If this is the first time you have started the Experimental Instance, the Choose Default Environment Settings dialog appears just like when you first time launch Visual Studio after installation.

This is an instance of Visual Studio that hosts the FirstLook package — later you’re going to learn the concept behind. The menu command implemented by this freshly generated package can be seen in the Tools menu as Figure 8 shows it.

f0308

Figure 8: The menu command item appears in the Tools menu

When you click the Simple Message command, it pops up a message box telling you it was displayed from the FirstLook package.

The package also registered some branding information that can be seen in the Help|About dialog as Figure 9 shows.

f0309

Figure 9: Branding information of the FirstLook package

Nothing call tell more about your VSPackage than its source code. But before deep-diving into it, let’s treat important concepts about packages.

Concepts behind Visual Studio Packages

A VSPackage is the principal architectural unit of Visual Studio. As you already know, Visual Studio IDE itself is the Shell hosting a set of VSPackages working together with each other and with the Shell. The basic responsibility of a package is to provide a common container for extensibility objects. So, a VSPackage is a software module that is a unit not only from architectural point of view but also from deployment, security and licensing aspects.

Developers — including the developers of Visual Studio — create VSPackages to provide some extension to the VS IDE and group them into modules according to their functionality. These extensions can be:

  • Services. These are software objects that offer functionality for other objects in the same package or even for other packages. For example, the C# Language Service (as its name also tells) is a service.
  • User interface elements. Menus, toolbars, and windows can be used by developers to initiate some actions in the user interface, interact with, display messages, information and figures, and so on.
  • Editors. During development you write and modify program text to create applications. This task is the responsibility of an editor. Visual Studio 2010 has its own core text editor and you can extend it or even create your own editors.
  • Designers. Application creation is not just simply a text-typing activity. There are many visual tools known as designers that allow an alternative representation and design of modules, components, parts or even full applications. Well-known examples are the Windows Forms designer, The WPF Forms designer, the ASP.NET page designer or the Data Table designer.
  • Projects. When developing applications you generally work with a large number of files. A project is an organization of source files and resources. A project not just simply stores these files but also defines operations with them, allows building, debugging and deploying the products created from source files.

 

It is natural in .NET that you can divide your functional units into separate assemblies where consumer assemblies will reference other service assemblies. The same principle works for VSPackages: an assembly containing a package can reference other assemblies that may contain not just helper types but even extensibility object types.

An assembly — as the smallest physical deployment unit in .NET — may contain more than one VSPackage. Although generally only one package is encapsulated in an assembly, you may have many reasons to group more packages in one assembly — including deployment considerations.

The Package Load Key

The previous versions of Visual Studio checked the package before loading them into the process space of the Shell. Any VSPackage should have been “sealed” with a so-called Package Load Key (PLK) and this key was verified during package load time. PLK was not a digital signature or a full hash, because it was calculated from a few information fields in the package. PLK could have been requested from Microsoft through a webpage: the developer specified a few well-defined attributes of the package and some logic calculated the PLK value. This value was embedded as a resource into the assembly representing the package.

Every time the package was loaded, the Shell checked the PLK against the package attributes it had been created from. Should have been this check fail, the Shell would have refused loading the package. This PLK mechanism did not mean that a developer had to request a new PLK for each package modification. While no basic information the PLK had been generated from was changed, the package continued to load.

Although this concept had been seemed useful, in the real life in had no real advantage. To be honest, in most of the cases it was the root cause of deployment issues, in many scenarios it raised more problems than it solved.

In the new Visual Studio 2010 the Shell does not use the Package Load Key to check packages before loading them into the memory.

On-demand Loading of Packages

You can imagine that complex packages like the C#, VB, F# or C++ languages with all of their “accessories” could consume many system resources by terms of memory and CPU. If you do not use them they do not press the CPU, but they might use the memory if they sit within the Visual Studio process space. If you create a project using F# you actually do not need services belonging to other languages, so why to load them into the memory at all?

The architects of Visual Studio implemented the package load mechanism so that packages are loaded into the memory at the first time when an event requiring the presence of the package is raised. These events can be one of the followings:

  • Command activation. The user (or some running code) activates a menu or toolbar command (or even a command that cannot be accessed from UI) served by a package which has not been loaded yet. It does not matter if the user has clicked on a menu item or the running code has activated it with a “virtual click” the result is the same.
  • Object or service request. The Shell is about to use an object or a service in a package not loaded yet. For example a tool window should be displayed or a service function is about to be executed.
  • Context change. The Shell can enter into certain user interface contexts. For example, when you start debugging a project, the Shell enters into the Debugging context. When a solution with a single project is loaded, the Shell enters into the SolutionHasSingleProject context. You can declare that a package should be loaded as the Shell enters in a certain context. Visual Studio has a few predefined contexts, but you can also define your own ones.

So, if you do not need a package during the whole IDE session, it does not consume the memory at all. Should you click on a menu item activating a command sitting in a package which has not been loaded yet the IDE will immediately load and initialize it. Should you ask for a tool window in a package not in the memory yet, the IDE will start loading it.

Binding package loading with a context change is generally required where your package want to subscribe for events raised in Visual Studio. You cannot bind the event either to command activation or object or service requests, because in order your package could work you have to subscribe to events. The code to create subscriptions is generally put into the initialization code. But you cannot run any code belonging to a package while it is not loaded into the memory! In this case you declare that the best context (the latest possible) to load the package. If your package logic requires, you can specify the NoSolutionExists context. Visual Studio enters into this context immediately when the Shell is loaded and ready to function, so packages bound to this context load at Visual Studio startup time.

Note: Be frugal with system resources if you have to load a package at Visual Studio startup time. Allocate only resources that are indispensable to carry out the required initialization at startup time.

Package Siting

When you develop a package it is an independent piece of code. When it is loaded into Visual Studio it becomes an organic part of the IDE:

  • Your package can access services and objects provided by the Shell and other packages.
  • The Shell and other packages can access the objects and services you proffer them.

The process of making a package physically integrated into the Shell is called siting. While the package is not sited, its functions cannot be used from outside. From the same reason the package can be only partially initialized, because it cannot touch any objects or services through the Shell. As soon as the package gets sited, it is ready to finish its initialization and be fully functional. Siting happens when Visual Studio loads the package.

The object type representing your package must implement an interface called IVsPackage (you are going to learn details later in this chapter) and must have a default constructor.

Loading a package contains the following steps:

  • The Shell creates an instance of the object type representing your package by invoking its default constructor.
  • The Shell calls the SetSite method of the object instance — IVsPackage defines this method — and passes a so-called service provider instance which can be used by the package to query objects in order to access services implemented by the Shell or other packages.
  • The Shell allows your package to finish its initialization. In the first step during the construction call the service object did not have any contact with the Shell. After siting all initialization steps invoking Shell services can be carried out.

Although siting physically integrates your package functionally with Visual Studio, functional integration may require some additional — and sometimes complex — steps depending on what your package is intended to do.

Package Registration

Visual Studio must keep track of packages in order to load and use them. Of course, the most flexible would be some kind of discovery where the Shell can look around only in the file system to guess out which entities represent packages. The .NET framework supports and intensively uses metadata (attributes) that can represent the information you can use for this purpose. You can even load an assembly so that only the metadata part is read from the file system and put into the memory. Although you can imagine this mechanism could work, it is not used by the Shell in this way.

The reason is that the roots of Visual Studio go back to the COM era. Packages are COM objects and can be created not only in managed code but also in native code using the Win32 API with any language including C++, Delphi and others. So, not surprisingly Visual Studio uses the registry to keep information about packages.

Although the registry is used to store configuration information about Visual Studio settings, developers and package users are not bothered with registration issues. The new deployment mechanism (through VSIX files) implemented in Visual Studio 2010 takes away this task. When Visual Studio is started, its discovery mechanism collects the information to be entered into the registry and does all the registration process on the fly. Developers perceive they do installation only by copying files and this resembles to the great mechanism we are using with the .NET Framework.

Package Information in the Registry

Packages are loaded into the memory on-demand. To effectively use this approach, Visual Studio stores the registration information about packages in a way so that this information could be accessed from the direction of objects to be used. For example, one kind of object that could trigger package loading is a tool window. A tool window has its own identity. When it is about to be created in order to be displayed, Visual Studio turns into the registry and addresses the corresponding key with the tool window identity. Under that key there is information stored about the identity of the package owning and implementing the tool window. Using this identity Visual Studio finds the registry key containing the package information and loads the package into the memory accordingly. The identity of packages and objects is represented by a GUID.

Figure 10 shows a few registry keys that store package-related information for Visual Studio.

f0310

Figure 10: Package and object information in the registry

Assume that Visual Studio is about to create a service instance. It uses the Services registry key and according to the service identity it finds the package. Figure 11 illustrates the service key of the Class Designer Service. At the left side you can see the subkey named by the GUID identifying the service. At the right side you see the corresponding package ID in the default value under the service key.

f0311

Figure 11: Service information in the registry

Visual Studio uses the same approach to find owner packages for any other objects.

There is one important thing to treat about package information in the registry. Packages can add their own user interface items to the Visual Studio IDE in form of menus and toolbars. If this UI information were created during the package initialization time, Visual Studio would need to load the package at startup time in order to present the package-dependent UI to the users. This approach would demolish the whole concept of on-demand loading.

Instead, the package uses a declarative way to define the user interface that should be displayed in the IDE at startup time. This information is encapsulated into the package assembly as an embedded resource. During the registration process Visual Studio extracts this resource information and merges it with its standard menus. Each user interface element — the commands they represent — is associated with the identity (GUID) of the owner package, so the Shell knows which package to load when a command is activated.

Visual Studio Experimental Instance

When you started the FirstLook package a new instance of Visual Studio was launched with the “Experimental Instance” text in its caption. What is that Visual Studio instance and how did it get to the computer?

Visual Studio Experimental Instance is a test bed to run and debug Visual Studio packages during the development and test phase. It is not a new installation of Visual Studio. It is the same devenv.exe file you use normally. But why you need it?

As it’s been mentioned earlier the package is registered — information is written into the system registry — in order it could integrate with Visual Studio. Every time you build and run a package some information goes into the registry. When you modify the package it might affect also the information in the registry. You can imagine what an unexpected confusion it can lead that you always modify the registry under the Visual Studio instance you actually use to develop and debug a package? What if your package does not work or even worse it prevents Visual Studio start correctly or even causes a crash? How would you fix the pollution of registry?

That is the point when Visual Studio Experimental Instance comes into the picture. The Experimental Instance is simply another instance of Visual Studio that picks up its settings from a different place — including configuration files and registry keys.

The devenv.exe keeps its configuration settings in the system registry in the CURRENT_USER hive under the Software\Microsoft\VisualStudio\10.0_Config key. When Visual Studio runs it reads out the configuration information from these keys by default. With the /rootsuffix command line parameters the root key used by devenv.exe can be changed.

The VSPackage Wizard sets up the package project so that the devenv.exe uses the /rootsuffix Exp command line parameter when running or debugging the package. By doing it so devenv.exe will use the Software\Microsoft\VisualStudio\10.0Exp_Config registry key under the CURRENT_USER registry hive. So running the package with the Start Debugging (F5) or Start Without Debugging (Ctrl+F5) functions will launch the Visual Studio Experimental Instance using this registry key.

The build process of a package copies the package binaries and the so-called VSIX manifest information to a well-known location under the current user’s application data folder. When the Experimental Hive starts, it discovers the package in the folder and uses the information found there to enter the package information into the registry key consumed by the Experimental Instance.

Using the Experimental Instance prevents you polluting the registry of the Visual Studio instance used for the normal development process. However, making mistakes, recompilations and faulty package registrations does not prevent putting junk or leaving orphaned information in the Experimental Instance registry. Making an appropriate cleanup could be very complex and dangerous if you would do it by delving in the registry.

Cleaning up packages from the Experimental Instance’s registry is quite easy! The Visual Studio SDK installs the CreateExpInstance.exe utility and adds it to the Visual Studio 2010 SDK menu items under the Tools folder with the name “Reset the Microsoft Visual Studio 2010 Experimental Instance”. Running this utility will reset the registry key belonging to the Experimental Hive to the state after the installation of VS SDK.

Note: If you develop Visual Studio packages you can get into situations several times where your package which worked before seems suddenly stop working. In majority of these cases the cause is the pollution of Visual Studio registry. There can be many orphaned objects in the registry as a result of continuous modification and rebuild of packages, and that can cause problems. If you run in such a situation, reset the Experimental Instance and then build your package with the Rebuild All function of Visual Studio. This procedure often helps.

Diving into the Package Source Code

You have already created a FirstLook project with the VSPackage wizard and by now you have a good overview about the basic concepts behind packages. Now we go into details and look how those concepts and ideas are reflected in the source code.

When the VSPackage Wizard generated the code according to the parameters we specified on the wizard pages, it made a lot of work at the background. The wizard carried out the following activities:

  • Generation of a class library project in C#.
  • Adding references to this project for the interoperability assemblies required to access Visual Studio functionality.
  • Creating resources used by the package and other resources used by the registration process.
  • Adding new MSBuild targets to the project to support the build and registration process of the package.
  • Generation of types responsible for implementing the package functionality.
  • Setting up the debug properties of the project to start Visual Studio Experimental Instance.

Table 1 summarizes the source files in the FirstLook project.

Table 1: FirstLook source files generated by the VSPackage wizard

Source File Description
source.extension.vsixmanifest This is the so-called VSIX manifest file which plays vital role in the discovery and registration mechanism of Visual Studio extensions.
FirstLook.vsct The so-called command table file storing the definition of the menus and commands to be merged into the Visual Studio IDE during the registration process.
FirstLookPackage.cs Class implementing the simple functionality of the package.
GlobalSupressions.cs Attributes used to suppress messages coming from the static code analysis.
Guids.cs GUID values used to identify the package and command objects within the package.
Key.snk Signing key used to generate the strong name for the package assembly.
PkgCmdID.cs Constants for identifying command values.
Resources.resx Resource file to store your functional package resources — resources you use according to the functions you implement in the package.
VSPackage.resx Resource file to store package infrastructure resources — those resources which are used by Visual Studio to integrate your package into the IDE.

The wizard added several assemblies to the class library project. Table 2 summarizes their roles. Their names start with the Microsoft.VisualStudio, this prefix is omitted in the table for the sake of clarity.

Table 2: Interoperability assembly references in the project

Source File Description
~.Shell.Interop This assembly defines several hundreds of core interoperability types (interfaces, structures, enumerations, classes, etc.).
~.Shell.Interop.8.0, ~.Shell.Interop.9.0 and ~.Shell.Interop.10.0 There are COM types new in VS 2005, VS 2008 and VS 2010 IDEs. The interoperability wrappers of them are defined in these assemblies where the 8.0 suffix is for VS 2005, the 9.0 suffix for VS 2008 while the 10.0 suffix for VS 2010.
~.Shell.Interop.Immutable.10.0 A few abstract and enumeration types used for package registration attributes.
~.OLE.Interop There are a few hundred of standard OLE types and interfaces. This assembly provides wrapper types for them.
~.Shell.9.0 The core types of the Managed Package Framework. There is a separate version for VS 2008 with the 9.0 suffix. If you work with VS 2008, you should use this assembly.
~.TextManager.Interop Interoperability assembly with wrapper types to access text editor and text management functionality. Although this assembly is referenced by the project, it is not used in the package you’ve created.

All assemblies having Interop in their names contain only proxy type definitions to access the core Visual Studio COM service interface and object types.

Package Type Definition

Now, let’s see the source code of the package! The wizard added many useful comments to the generated source files. In the code extracts listed here those commands are cut out to make the listings shorter and improve the readability of the code. The indentation has also been changed a bit for the same purpose.

Listing 1 shows the source code of the most important file in our project named FirstLookPackage.cs. This file implements the type representing our package:

Listing 1: FirstLookPackage.cs

  1. using System;
  2. using System.ComponentModel.Design;
  3. using System.Diagnostics;
  4. using System.Globalization;
  5. using System.Runtime.InteropServices;
  6. using Microsoft.VisualStudio.Shell;
  7. using Microsoft.VisualStudio.Shell.Interop;
  8.  
  9. namespace DeepDiver.FirstLook
  10. {
  11.   [PackageRegistration(UseManagedResourcesOnly = true)]
  12.   [InstalledProductRegistration("#110", "#112", "1.0", IconResourceID = 400)]
  13.   [ProvideMenuResource("Menus.ctmenu", 1)]
  14.   [Guid(GuidList.guidFirstLookPkgString)]
  15.   public sealed class FirstLookPackage : Package
  16.   {
  17.     public FirstLookPackage()
  18.     {
  19.       Trace.WriteLine(string.Format(CultureInfo.CurrentCulture, "Entering constructor for: {0}", this.ToString()));
  20.     }
  21.  
  22.     protected override void Initialize()
  23.     {
  24.       Trace.WriteLine(string.Format(CultureInfo.CurrentCulture, "Entering Initialize() of: {0}", this.ToString()));
  25.       base.Initialize();
  26.  
  27.       // Add our command handlers for menu (commands must exist in the .vsct file)
  28.       OleMenuCommandService mcs = GetService(typeof(IMenuCommandService)) as OleMenuCommandService;
  29.       if (null != mcs)
  30.       {
  31.         // Create the command for the menu item.
  32.         CommandID menuCommandID = new CommandID(GuidList.guidFirstLookCmdSet, (int)PkgCmdIDList.cmdidShowMyMessage);
  33.         MenuCommand menuItem = new MenuCommand(MenuItemCallback, menuCommandID);
  34.         mcs.AddCommand(menuItem);
  35.       }
  36.     }
  37.  
  38.     private void MenuItemCallback(object sender, EventArgs e)
  39.     {
  40.       // Show a Message Box to prove we were here
  41.       IVsUIShell uiShell = (IVsUIShell)GetService(typeof(SVsUIShell));
  42.       Guid clsid = Guid.Empty;
  43.       int result;
  44.       Microsoft.VisualStudio.ErrorHandler.ThrowOnFailure(uiShell.ShowMessageBox(
  45.                  0,
  46.                  ref clsid,
  47.                  "FirstLook",
  48.                  string.Format(CultureInfo.CurrentCulture, "Inside {0}.MenuItemCallback()", this.ToString()),
  49.                  string.Empty,
  50.                  0,
  51.                  OLEMSGBUTTON.OLEMSGBUTTON_OK,
  52.                  OLEMSGDEFBUTTON.OLEMSGDEFBUTTON_FIRST,
  53.                  OLEMSGICON.OLEMSGICON_INFO,
  54.                  0,        // false
  55.                  out result));
  56.     }
  57.   }
  58. }

The FirstLookPackage class becomes a working package by inheriting the behavior defined in the Package class of the Microsoft.VisualStudio.Shell namespace and by using the attributes decorating the class definition.

The Package base class implements the IVsPackage interface that is required by Visual Studio in order to take an object into account as a package. This interface provides a few methods managing the lifecycle of a package and also offers methods to access package related objects like tool windows, options pages, and automation objects. One of the most important of them is the SetSite method having the following signature:

  1. int SetSite(IServiceProvider psp);

Visual Studio calls this method immediately after the package has been instantiated by its default constructor. The psp parameter is an instance of System.IServiceProvider and this object is the key in keeping contact between the package and the IDE: any time the package requests a service object from its context—from the IDE—the psp instance is used at the back, however, the implementation of Package hides it from our eyes.

The overridden Initialize method is called after the package has been successfully sited. This method has to do all the initialization steps that require access to services provided by the Shell or other packages. Should you move this code to the package constructor you would get a NullReferenceException because at that point all attempts to access the Shell would fail as the package is not sited yet and actually has no contact with any shell objects.

The package constructor should do only inexpensive initialization that you would put normally to a constructor. Any other kind of initialization activities should be put to the overridden Initialize method. If you have some other expensive initialization activity that can be postponed, you should do them right when there’s no more time to delay them.

In this case the Initialize method binds the single menu command provided by the FirstLookPackage with its event handler method called MenuItemCallback:

  1. protected override void Initialize()
  2. {
  3.   Trace.WriteLine(string.Format(CultureInfo.CurrentCulture, "Entering Initialize() of: {0}", this.ToString()));
  4.   base.Initialize();
  5.  
  6.   // Add our command handlers for menu (commands must exist in the .vsct file)
  7.   OleMenuCommandService mcs = GetService(typeof(IMenuCommandService)) as OleMenuCommandService;
  8.   if (null != mcs)
  9.   {
  10.     // Create the command for the menu item.
  11.     CommandID menuCommandID = new CommandID(GuidList.guidFirstLookCmdSet, (int)PkgCmdIDList.cmdidShowMyMessage);
  12.     MenuCommand menuItem = new MenuCommand(MenuItemCallback, menuCommandID);
  13.     mcs.AddCommand(menuItem);
  14.   }
  15. }

First it calls the Initialize method of the base class — Package in this case. Omitting the call to the base implementation would prevent the package running correctly. Look at the call of GetService in Line 7! If you could select a method that is especially very important when creating Visual Studio Extensions, probably the GetService method is that one! This method is implemented by the Package class — many other Managed Package Framework objects also implement this method — in order to request service objects from the environment. GetService has one type parameter — it’s called service address — that retrieves a service object implementing the service interface specified by the address type.

So, Line 7 obtains an OleMenuCommandService instance that you can use to bind event handlers to so-called command objects. In Line 11 and 12 a CommandID instance is created to address the command to be put to the Tools menu. In Line 12 a MenuCommand instance is created to assigns the MenuItemCallback method as a response for the command specified with the CommandID instance. Line 13 entitles the menu command service to handle events related to the command. The result of this short initialization code is that your package handles the event when the user clicks the Simple Message menu item in the Tools menu by executing the MenuItemCallback method. In the next chapter you will find all nitty-gritty details about the command handling concepts used in Visual Studio and there you will learn much more about the initialization approach used here.

The MenuItemCallback method uses the IVsUIShell service to pop up a message box from within the IDE.

Registration Attributes

By now you know that packages are registered with Visual Studio in order to support the on-demand loading mechanism and allow merging menus and toolbars into the user interface of the IDE. The information to be registered is created during the build process from attributes assigned to the package class:

  1. [PackageRegistration(UseManagedResourcesOnly = true)]
  2. [InstalledProductRegistration("#110", "#112", "1.0", IconResourceID = 400)]
  3. [ProvideMenuResource("Menus.ctmenu", 1)]
  4. [Guid(GuidList.guidFirstLookPkgString)]
  5. public sealed class FirstLookPackage : Package
  6. {
  7.   // --- Package body omitted
  8. }

Packages are COM objects and so they must have a GUID uniquely identifying them. The Guid attribute is used by the .NET framework to assign this GUID value to a type. All attributes above except Guid are derived from the RegistrationAttribute class which is the abstract root class for all attributes taking a role in package registration. Table 3 describes the attributes decorating the FirstLookPackage:

Table 3: Registration attributes in FirstLookPackage

Source File Description
PackageRegistration Adding this attribute to a class, the build process will handle it as a package and looks for other attributes to prepare the package registration according to your intention. In the example this attribute sets the UseManagedResourcesOnly flag to tell that all resources used by the package are described in the managed package and not in a satellite DLL.
InstalledProductRegistration This attribute is responsible to provide information to be displayed in the Help|About dialog in the IDE. The constructor of this attribute requires four arguments with the following meanings:
  • The first and second strings provide the name and the description of the package. The “#” characters indicate that these values should be looked up in the package resources with the IDs following “#”.
  • The third “1.0” parameter is the product ID (version number).
  • The fourth parameter (IconResourceID) tells which icon to use for the package.
All resources (name, description and icon) should be defined in the VSPackage.resx file.
ProvideMenuResource This attribute is to create registry entries about menu and toolbar items provided by the package. Visual Studio uses the embedded resources here to merge the package menus into the Visual Studio menus.
The attribute has two parameters. The first is the so-called resourceID. This value is set to Menus.ctmenu as during the build process the VSCT compiler uses this value by default when adding the binary representation of the .vsct file to the package resources. The second parameter is called versionID and it plays important role in the caching mechanism of resources. In the next chapter you are going to examine the role of this attribute in details.

There are many other registration attribute beside the ones in the table above, later in the book we are going to meet a few of them. You are not constrained to apply only the registration attributes defined by the Managed Package Framework, and you can define your own attributes. Any of them including yours are handled on the same way by the build process as the predefined ones.

The Command Table

The wizard generated a file named FirstLook.vsct. It is an XML file and the file extension refers to the acronym coming from the “Visual Studio Command Table” expression. The schema of the XML file defines the command table owned by the package.

The command table is transformed into a binary format during the build process and is embedded into the package assembly as a resource. During the registration phase the ID of this resource is put into the registry. When Visual Studio starts, loads this binary resource information and merges it with the menus of the IDE including toolbars and context menus.

In order to avoid menu merges every time Visual Studio is launched, the IDE uses a cache mechanism and carries out the merge process only once for each package.

The next chapter will treat this mechanism and the structure of the command table in details. Listing 2 shows you the command table described in the FirstLook.vsct file.

Listing 2: FirstLook.vsct

  1. <?xml version="1.0" encoding="utf-8"?>
  2. <CommandTable xmlns="http://schemas.microsoft.com/VisualStudio/2005-10-18/CommandTable"
  3.               xmlns:xs="http://www.w3.org/2001/XMLSchema">
  4.   <Extern href="stdidcmd.h"/>
  5.   <Extern href="vsshlids.h"/>
  6.   <Extern href="msobtnid.h"/>
  7.  
  8.   <Commands package="guidFirstLookPkg">
  9.     <Groups>
  10.       <Group guid="guidFirstLookCmdSet" id="MyMenuGroup" priority="0x0600">
  11.         <Parent guid="guidSHLMainMenu" id="IDM_VS_MENU_TOOLS"/>
  12.       </Group>
  13.     </Groups>
  14.  
  15.     <Buttons>
  16.       <Button guid="guidFirstLookCmdSet" id="cmdidShowMyMessage" priority="0x0100" type="Button">
  17.         <Parent guid="guidFirstLookCmdSet" id="MyMenuGroup" />
  18.         <Icon guid="guidImages" id="bmpPic1" />
  19.         <Strings>
  20.           <CommandName>cmdidShowMyMessage</CommandName>
  21.           <ButtonText>Simple Message</ButtonText>
  22.         </Strings>
  23.       </Button>
  24.     </Buttons>
  25.    
  26.     <Bitmaps>
  27.       <Bitmap guid="guidImages" href="Resources\Images_32bit.bmp" usedList="bmpPic1, bmpPic2, bmpPicSearch, bmpPicX, bmpPicArrows"/>
  28.     </Bitmaps>
  29.   </Commands>
  30.  
  31.   <Symbols>
  32.     <GuidSymbol name="guidFirstLookPkg" value="{d55758eb-6581-48fe-930b-f3536f43b6f0}" />
  33.     <GuidSymbol name="guidFirstLookCmdSet" value="{05da2180-8d8e-4822-913b-b6a9012c4b2b}">
  34.       <IDSymbol name="MyMenuGroup" value="0x1020" />
  35.       <IDSymbol name="cmdidShowMyMessage" value="0x0100" />
  36.     </GuidSymbol>
  37.     <GuidSymbol name="guidImages" value="{49ba23b3-1631-483d-a095-003cb157f55d}" >
  38.       <IDSymbol name="bmpPic1" value="1" />
  39.       <IDSymbol name="bmpPic2" value="2" />
  40.       <IDSymbol name="bmpPicSearch" value="3" />
  41.       <IDSymbol name="bmpPicX" value="4" />
  42.       <IDSymbol name="bmpPicArrows" value="5" />
  43.     </GuidSymbol>
  44.   </Symbols>
  45.  
  46. </CommandTable>

In this listing all comments placed into the generated file are omitted for saving space. However, it is worth to read those comments to have a better understanding of the command table structure.

The .vsct file tells a lot about how Visual Studio is architected, how it solves the coupling of functions (commands) and user interface elements.

  • Commands (actions to execute) are separated from the user interface element triggering the command. The same command can be assigned to different menus and toolbars; they will use the same action.
  • Commands used together can be grouped and simply merged into existing menus by using the command group representation. It is much easier then coupling commands with hosting menus one-by-one.
  • Elements are identified by symbols rather than using explicit values. This makes the coupling less error-prone: values of symbols must be defined only once, and the VSCT compiler can check for mistyping.

The root element of a .vsct file is the CommandTable element. As you can see all related elements are defined by the http://schemas.microsoft.com/VisualStudio/2005-10-18/CommandTable namespace. No doubt, the most important element is Commands, because this node defines commands, their initial layout and behavior.

Any command in the VS IDE must belong to the IDE itself or to a package. To assign a command to the appropriate (owning) VSPackage, the package attribute of the Commands element must name the GUID of the corresponding package.

Commands node can have a few child elements; each has a very specific role.

Group elements define so-called command groups; each of them is a logical set of related commands that visually stand together. In the FirstLook.vsct file we have a Group element that holds only a Button. A button represents a piece of user interface element the user can interact with, in this case a menu item that can be clicked. The Parent element defines the relationship between elements, for example the Button element defined above is parented in the Group.

Toolbars and menus would be poor without icons helping the user to associate a small image with the function. The Bitmap nodes allow defining the visual elements (icons) used in menus.

The Symbols section is a central place in the command table file where you can define the identifiers to be used in the other parts of the .vsct file. You can use the GuidSymbol element to define the “logical container GUID” and the nested IDSymbol elements to provide (optional) identifiers within the logical container. The name and the value attribute of these elements do exactly what you expect: associate the symbol name with its value.

The VSPackage Wizard put the generated GUID values into the FirstLook.vsct file but they also can be found in the Guids.cs file. The PkgCmdID.cs file defines constant values for the IDSymbol values used by package commands. These three files must be kept consistent, so if you change a GUID or a command identifier, the changes should be tracked in the other files as well; otherwise your package will not work as expected.

Package Resource Files

The FirstLook project has two resource files: Resources.resx and VSPackage.resx. They both utilize the resource handling mechanism in the .NET Framework, but have different roles.

Resources.resx is to store functional resources that are consumed by the objects and services of your package. For instance, you can store error messages, prompt strings, UI elements, logos, and so on in this resource file and access them programmatically through the static members of the Resources class generated by the ResXFileCodeGenerator custom tool attached to the .resx file.

VSPackage.resx can store resources just like Resources.resx, but its primary role is to embed package infrastructure resources. This resource file does not use the ResXFileCodeGenerator custom tool and so does not generate any helper class to access resources.

As you remember the package is decorated with the InstalledProductRegistration attribute which refers to resource identifiers 110, 112 and 400:

  1. [InstalledProductRegistration("#110", "#112", "1.0", IconResourceID = 400)]

These IDs refer to string and icon resources in the VSPackage.resx file as shown in Figure 12.

f0312

Figure 12: String resources in VSPackage.resx

Package resources will be extracted from the content of the VSPackage.resx file, so if you put them in the Resources.resx file, the package will not find the resource. Although you can put functional resources into VSPackage.resx file, their recommended place is the Resources.resx file.

The Package Build Process

Understanding the package build process can help a lot when you are about to debug or deploy your application. In this part you’ll learn the steps of this process in details.

Building a package is not simply compiling the package source code into a .NET assembly. There are other important steps to complete in order to use the package either in the Experimental Instance or in its productive environment.

When the wizard generates the package it adds new build targets to the .csproj file of the corresponding class library. You can discover these entries by first unloading the project and then editing the project file. If you want to try it, first right-click on the project file in Solution Explorer and use the Unload Project function, then activate the Edit FirstLook.csproj command also with right-click. When you scroll down to the bottom of the file you can discover the following entries:

  1. <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
  2. <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\VSSDK\\uinput1?
  3.   Microsoft.VsSDK.targets" />
  4.  

The first Import entry can be found in any C# language projects to invoke the C# compiler and all the other tools (for example the resource compiler) to create the assemblies from the source project. The second Import entry is the one added by the VSPackage Wizard. The .targets file specified here contains Visual Studio SDK related build targets. If you would like to have a look at this file, you can find it in the MSBuild\Microsoft\VisualStudio\v10.0\VSSDK folder under Program Files. This book is not about MSBUILD, so you won’t find more explanations about what the build targets describe and how they internally work, instead, here are the steps of the package build process:

  • The Resources.resx and VSPackage.resx files are compiled into the corresponding .resource files.
  • With the help of the vsct.exe utility the content of the .vsct file belonging to the package is compiled into a binary file called CTO file. This file format is used by Visual Studio when merging the package menu and command information into the IDE menu.
  • The CTO file is merged into the VSPackage.resource file as a binary resource with the name of Menus.ctmenu.
  • The C# compiler is invoked to compile the project source code just like normally when we build a standard class library. During this step the Resources.resources file and the VSPackage.resources files are embedded into the assembly.
  • The CreatePkgDef.exe utility is executed and it scans the assembly for registration metadata information. Each registration attribute is translated to corresponding registry data. The utility is parameterized so that it creates a .pkgdef text file containing the information that is to be entered into the system registry.
  • The binaries of the package (including the .dll and .pdb file), the corresponding .pkgdef file and the VSIX manifest file are zipped into a file with .vsix extension. This .vsix file is the installation kit of the package. You will find this file just beside the binaries (in the bin\Debug or bin\Release or maybe in another folder depending on the build configuration). With double clicking on this file you can start the Visual Studio Extension Installer utility.
  • The .vsix file is installed in your LocalAppData folder under the Extensions subfolder of the Visual Studio Experimental Instance. The location of this folder depends on your user account and profile type. For example, if your user name is jsmith, you have installed Windows 7 on your C: drive and you have a local profile the build process will look for the C:\Users\jsmith\AppData\Local\Microsoft\VisualStudio folder and install the .vsix file under the 10.0Exp\Extensions subfolder. The extension will be enabled (setting a key in the registry).

As a result of the build process the package is available in the Experimental Instance. The next time you start the Experimental Instance, it scans the Extensions folder, uses the .pkgdef file of your package to create the appropriate registry settings, the package’s menus gets merged into the IDE, so your package is ready to run.

Debugging Visual Studio Packages

Anyone who develops software creates programming mistakes. Majority of them can be caught during a simple or more complex code review. Many of them are obvious and you can find them in the code after observing the faulty behavior. There are a few of them which cannot be easily caught without using a debugger.

Developing VSPackages is the same story. Sooner or later you find yourself debugging a package and searching for a bug. This book does not want to go into details about debugging techniques; this is definitely not its topic. However, you will learn how easy is to debug your package and what is going behind the scenes.

To debug or run a package you should set it as the startup project. If your package is the only project is the solution, it is already marked so. If you have more projects in the solution, you should mark any VSPackage project as the startup project.

Independently if you run a package with or without debugging, the Visual Studio Experimental Instance is started. You can check it on the project property pages on the Debug tab as Figure 13 shows it for the FirstLook project.

f0313

Figure 13: Debug properties

You can see that devenv.exe is selected as the startup project and it is launched with the /rootsuffix Exp command line parameters. As you have learnt before this command line starts the Experimental Instance.

When you start the project with the Start Debugging (F5) function Visual Studio attaches the debugger to the Experimental Instance and so you can set breakpoints in Visual Studio. As your package running in the Experimental Instance reaches a breakpoint, you are taken back to the debug view as Figure 14 illustrates it. In this case a breakpoint was set within the Initialize method of the FirstLookPackage class.

f0314

Figure 14: The debugger in action

You can use the same techniques for debugging a VSPackage as for any other applications. All debugging features of Visual Studio are accessible: you can watch variables, evaluate expressions, set up conditional breakpoints, and so on.

There are cases when you would like to trace your application without a debugger using trace messages. You can follow this practice with Visual Studio. The simplest one is writing to the Debug pane of the Output window. You can learn about this topic in Chapter 3.

 

Deploying a Package

It is very comfortable to use the Experimental Instance while developing a package. The build process takes care about setting up your package to work, so you can use either the Start Debugging or Start Without Debugging commands to try what you’ve created. However, when your package is ready for distribution you should care about deployment questions.

Package Deployment in the Past

With Visual Studio versions preceding 2010 developers had to do some extra activities to prepare packages for deployment and it has a few potential pitfalls. The two main issues were that you needed to obtain a so-called Package Load Key (PLK) through a web page and take care of entering the required entries into the registry to allow Visual Studio recognize and integrate your package.

¾ Any change in package information like name, GUID, company or version required obtaining a new PLK. The Experimental Hive (this is what is now called Experimental Instance) did not check the PLK by default, so it often happened that developers faced with a wrong (missing or not renewed) PLK only after the installation kit was built and tested in the production Visual Studio environment.

¾ While the build process automatically registered the package under the Experimental Hive, developers had to create their own registration mechanism in the installation kit. It was not difficult, but because it was not automatic, forgotten registration updates could have led to annoying issues.

The VSIX installation

The new deployment mechanism built into Visual Studio 2010 removes this pain and provides an easy and straightforward way for package deployment.

Generally the easiest form of deploying an artifact is if you have an installation kit. The package build process as treated earlier creates this installation kit as a .vsix file containing the package binaries and some additional information. You can distribute your package by simply distributing the .vsix file to your customers. When they receive it, the Visual Studio Extension Installer utility can be started with double clicking on the .vsix file as Figure 15 illustrates.

f0315

Figure 15: Installing a VSIX file

When you click install the content of the VSIX file will be installed to the specified Visual Studio instance.

If you create a package for a broad set of customers or for the community, you can upload the VSIX file to the Visual Studio Gallery. The new Shell of Visual Studio contains a great tool called Extension Manager that is able to search this gallery for extensions, install or remove them, and keep track of installed extensions as well as managing their updates. Figure 16 shows a screenshot of the Extension Manager browsing the extensions available on Visual Studio Gallery.

f0316

Figure 16: Browsing Visual Studio Gallery with the Extension Manager

You can select any of the components while browsing, and on the right pane of the window you find some more details about the highlighted item. With the More Information link you will be directed to component’s home page on the Visual Studio Gallery. If you like this component, you can get it with the Download button just as others can obtain your uploaded components. The Extension Manager is the recommended way to obtain extensions. Because it runs within a Visual Studio instance, you can use it to install a separate set of components for your development environment and for the Experimental Instance. When using the Visual Studio Extension Installer utility your components will be installed under the normal development environment by default.

It was mentioned earlier that the build process packages the binaries and some other files into the VSIX file. In order the installation process could understand your .vsix installation file you need to create a so-called VSIX manifest file that is the soul of the installation kit. This file describes the metadata that is used as the set of instructions about what, where and how should be put during the setup. The VSPackage Wizard automatically creates this manifest for you and names the file as source.extension.vsixmanifest. You are probably not surprised that the manifest is an XML file with its own schema. When the FirstLook package was generated the wizard created the manifest shown in Listing 3:

 

Listing 3: source.extension.vsixmanifest

  1. <?xml version="1.0" encoding="utf-8"?>
  2. <Vsix Version="1.0.0" xmlns="http://schemas.microsoft.com/developer/vsx-schema/2010">
  3.   <Identifier Id="d55758eb-6581-48fe-930b-f3536f43b6f0">
  4.     <Name>FirstLook</Name>
  5.     <Author>DeepDiver</Author>
  6.     <Version>1.0</Version>
  7.     <Description xml:space="preserve">Demonstrates the basic VSPackage concepts</Description>
  8.     <Locale>1033</Locale>
  9.     <InstalledByMsi>false</InstalledByMsi>
  10.     <SupportedProducts>
  11.       <VisualStudio Version="10.0">
  12.         <Edition>Pro</Edition>
  13.       </VisualStudio>
  14.     </SupportedProducts>
  15.     <SupportedFrameworkRuntimeEdition MinVersion="4.0" MaxVersion="4.0" />
  16.   </Identifier>
  17.   <References>
  18.   </References>
  19.   <Content>
  20.     <VsPackage>|FirstLook;PkgdefProjectOutputGroup|</VsPackage>
  21.   </Content>
  22. </Vsix>
  23.  

The root element of the manifest structure is the VSIX element that uses the http://schemas.microsoft.com/developer/vsx-schema/2010 namespace. The manifest contains three sections:

  • Identifier is used to uniquely define the different installation packages. The information here is used by the setup mechanism to manage the initial setup and the updates using the Id attribute and Version element values. This section also contains information describing the package and attributes taken into account during the setup process.
  • References element contains a collection of dependencies. Each item is a Reference element which defines a dependency on another product. In the FirstLook.vsix sample the package contains one dependency.
  • The Content element is a collection of content items that are packed in the payload. It our case the content is a VSPackage where the value of the item is used to generate the .pkgdef file containing the package information.

When running the Visual Studio Extension Installer or using the Extension Manager, the VSIX manifest is used to determine how the VSIX package should be set up. The VSPackage content type tells the installer that the related FirstLook.pkgdef file will contain the information to be put into the registry in order to register the COM object representing a Visual Studio package. The FirstLook.pkgdef file that has been created during the build process contains the information in Listing 4:

Listing 4: FirstLook.pkgdef

  1. [$RootKey$\InstalledProducts\FirstLookPackage]
  2. @="#110"
  3. "Package"="{d55758eb-6581-48fe-930b-f3536f43b6f0}"
  4. "PID"="1.0"
  5. "ProductDetails"="#112"
  6. "LogoID"="#400"
  7. [$RootKey$\Packages\{d55758eb-6581-48fe-930b-f3536f43b6f0}]
  8. @="DeepDiver.FirstLook.FirstLookPackage, FirstLook, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8e5c6425e9b83cf4"
  9. "InprocServer32"="$WinDir$\SYSTEM32\MSCOREE.DLL"
  10. "Class"="DeepDiver.FirstLook.FirstLookPackage"
  11. "CodeBase"="$PackageFolder$\FirstLook.dll"
  12. [$RootKey$\Menus]
  13. "{d55758eb-6581-48fe-930b-f3536f43b6f0}"=", Menus.ctmenu, 1"

The content of this file resembles to the content of a .reg file that can be exported from or imported to the Windows registry. However, the .pkgdef file contains a few tokens closed between dollar signs. The values of these tokens are passed by the context of the .pkgdef file to the entity processing the file content.

For example, if you use the Visual Studio Extension Installer utility to process the .vsix file, the utility extracts the payload into the Microsoft\VisualStudio\10.0\Extensions subfolder under the LocalAppData folder of your user profile. The files are put not directly into the Extension folder but into the subfolder calculated from the Author, Name and Version elements of the manifest’s Identity section. In this case the payload includes the FirstLook.pkgdef and FirstLook.dll files beside a few others.

When Visual Studio starts, it recognizes that a new .pkgdef file is under the Extensions folder and processes it. It substitutes the $RootKey$ token with the corresponding registry root of Visual Studio 2010, $Windir$ with the current Windows installation folder, $PackageFolder$ with the encapsulating folder of the .pkgdef file. After Visual Studio startup finishes, all information required to find and load the package is entered into the registry. When the first action demanding the package is executed, Visual Studio can pick up and initialize it.

Summary

A VSPackage is the principal architectural unit of Visual Studio, a container for extensibility objects. It is also a unit from deployment, security and licensing aspects. Packages are not loaded immediately as Visual Studio starts, they are read into the memory on-demand at the first time when any of their objects or services is about to be used.

The process of integrating a package physically into the Shell is called siting. While the package is not sited, its functions cannot be used from outside. As soon as the package gets sited, it is ready to finish its initialization and be fully functional. Siting happens when Visual Studio loads the package.

Visual Studio keeps track of packages installed through registration, and package information is stored in the system registry under a specific Visual Studio key. With command line parameters this registration key can be suffixed in order to use another configuration set — even with separate package registration parameters.

The Visual Studio SDK sets up the Visual Studio Experimental Instance which is a test bed to run and debug Visual Studio packages during the development and test phases. The Experimental Instance is not a separate Visual Studio installation, it uses the same devenv.exe file but with different configuration settings.

VSPackages use a build process that contains some additional steps in order to prepare the packages for debugging or deployment. The easiest way to create a package is running the VSPackage Wizard which sets up the build process appropriately. During this process package infrastructure resources — like to so-called command table — are embedded into the package assembly, the package installation kit is created and installed under the Experimental Instance.

During the development phase packages run inside the process space of the Experimental Instance and the same debug techniques can be used for tracing and troubleshooting as for any other .NET applications.

VSPackage deployment in Visual Studio 2010 became really simple related to the preceding versions. The package installation kit is represented by a VSIX file that can be distributed directly to the users of your package or — and this way opens up brand new opportunities — uploaded to the Visual Studio Gallery. The Extension Manager built into the IDE can be used to browse, install, and remove VSPackages (and many other kinds of extensions) as well as to keep track of them.


Posted Mar 02 2010, 01:13 PM by inovak
Filed under: ,

Comments

Martin Filteau wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Tue, Mar 2 2010 17:38

Have you thought about self-publishing your book on lulu.com? I would buy a copy especially if it's color printed!

Sam wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sun, Mar 28 2010 11:49

Great article, but where are the other three articles about it? I couldn't find any evidence of chapter 2 here

inovak wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sun, Mar 28 2010 17:25

Hey Sam, the subsequent chapters are coming soon... Right now I'm really busy with the VS 2010 launch, so you can expect the next chapters after April 15.

Rodion Degtyar wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, May 19 2010 8:41

Man, I would definitely buy thisbook. All other books on the subject don't even scratch the surface. Looking forward to the next chapters.

Novák István szakmai blogja wrote Visual Studio 2010 Package Development cikkek
on Sat, May 22 2010 13:28

Már több, mint két éve dolgozom együtt a Visual Studio Extensibility redmondi és cambridge-i csapatával

Mathias wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Thu, May 27 2010 12:03

I would definitely buy your book. Thanks for publishing it here!

hammett wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sun, Jun 20 2010 18:02

I am MSFT and would buy this book! There's nothing like that out there. Have you reached MS Press? Also, self-publishing seems like a better idea.

inovak wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sun, Jun 20 2010 20:12

I plan to publish the book in August 2010, now I'm working on the last (7th) chapter.

Utkarsh wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Mon, Jun 21 2010 5:52

I would love to buy your book. I am from India and please let me know when it will be available in India.

Denis wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Mon, Jul 5 2010 0:57

I will buy your book too.

It is a shame that you cant publish your book.

There are absolutely no books about extending VS

(I know only 2 books, but one is obsolete, second is not very good).

Good luck. Don't give up!

Denis

P.S. Maybe you shoul ask at StackOverflow where you can publish your book? :)

Denis wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Mon, Jul 5 2010 1:00

Please create a tag for your book.

It will be easier to monitor what is the state of the book.

VS 2010 Package Development ??? Chapter 1:… « ctthang's Blog wrote VS 2010 Package Development ??? Chapter 1:&#8230; &laquo; ctthang&#039;s Blog
on Wed, Oct 20 2010 5:36

Pingback from  VS 2010 Package Development ??? Chapter 1:… «  ctthang's Blog

Andrei wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Dec 28 2011 0:11

I am currently writing a VS2010 extension and using some information from your site, thank you very much. However one question I still cannot find answer to: what is the best way to supply configuration information to the extension? And I mean non only something very specific, like a connection string, but a general config info which can be found in .config file. Right now I had to use ConfigurationManager.OpenMappedExeConfiguration to access custom config file. And since I am using Unity for DI and IoC, I had to do some custom assembly loading via AppDomain.CurrentDomain.AssemblyResolve. Seems a bit like overkill to me, no?

James Wiseman » VS 2010 Package Development wrote James Wiseman &raquo; VS 2010 Package Development
on Mon, Jul 30 2012 20:04

Pingback from  James Wiseman » VS 2010 Package Development

Yuanzhi.Tang wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Fri, Oct 12 2012 10:39

The code running steps as follows:

•C# invoke unmanaged C++ through managed C++;

•C++ site will create a new child thread and trigger C# OnChange method.

•C# site will tried to getService: IVsNavigationTool navTool = provider.GetService<SVsClassView, IVsNavigationTool>();

serviceProvider come from SMProject which implement System.IServiceProvider interface, and SMProject have member named SMPackage which inherit from Microsoft.VisualStudio.Shell.Package, SMProject will invoke SMPackage.GetService method to override IServiceProvider interface GetService method.

Comments: 

C# site in new created child Thread not main thread . If on C++ site , we can't create a new thread , just the GetService segment code runing in main thread , it is works ok.  And i tried to retrieve SVsClassView  & IVsNavigationTool, c# site code running in child thread, get Service will failed ...

Could you please give me any help??

Utkarsh wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Mon, Dec 17 2012 9:22

Any updates?

New Jersey DUI Arrest wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sun, Feb 10 2013 23:14

Very informative post.Much thanks again. Much obliged.

New Jersey Lawyer wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sun, Feb 10 2013 23:14

Thanks for the article.Thanks Again. Will read on...

canvas tablo wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Mon, Feb 11 2013 9:15

This is one awesome post.Thanks Again. Keep writing.

kanvas tablo wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Mon, Feb 11 2013 9:15

Enjoyed every bit of your article.Really looking forward to read more. Awesome.

ereleases chatrandom article wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Mon, Feb 11 2013 9:27

Thanks a lot for the article.Really thank you! Much obliged.

http://www.springbridge.co.uk/categories/Topsoil-/ wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sat, Feb 16 2013 12:36

I really enjoy the blog post.Really thank you! Fantastic.

buy imitrex generic wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sat, Feb 23 2013 21:38

PSSFxg Thanks a lot for the article post.Really thank you! Keep writing.

get more genuine twitter followers wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Tue, Feb 26 2013 19:34

Thanks for sharing, this is a fantastic article post.Really looking forward to read more. Cool.

vitamins to make hair grow faster wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Tue, Feb 26 2013 21:15

Thank you for your article post.Really thank you! Cool.

seo consulting wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Tue, Feb 26 2013 22:35

wow, awesome blog.Really looking forward to read more. Awesome.

earned money wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Tue, Feb 26 2013 22:54

Major thankies for the blog article.Thanks Again. Great.

Company Names wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Tue, Feb 26 2013 23:18

Great, thanks for sharing this article post.Thanks Again. Fantastic.

clear instagram search wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 0:28

Very neat article post. Really Cool.

Best Priced Home Audio and Video wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 0:29

Enjoyed every bit of your blog post.Much thanks again. Awesome.

vagas de emprego wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 2:04

I am so grateful for your post.Really looking forward to read more. Keep writing.

get instagram followers wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 2:19

I really like and appreciate your article.Really thank you!

empower network marketing system wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 3:03

I really like and appreciate your blog.Really looking forward to read more. Great.

buying and selling properties wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 3:41

wow, awesome post.Much thanks again. Great.

Kardashian sextape wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 4:56

Very good article. Fantastic.

trick photography book and special effects wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 5:20

I appreciate you sharing this blog article.Really looking forward to read more. Much obliged.

buy real instagram followers cheap wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 6:06

Great, thanks for sharing this blog article. Keep writing.

get more customers wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 6:59

Im thankful for the blog article.Thanks Again. Much obliged.

how to get alot of likes on instagram wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 8:01

Muchos Gracias for your article post.Really looking forward to read more. Great.

Nikon d7000 India price wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 8:38

Appreciate you sharing, great article post.Really thank you! Awesome.

wood working plans wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 8:49

I am so grateful for your blog article.Thanks Again. Really Great.

corporate travel wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 10:00

Major thankies for the article post.Thanks Again. Will read on...

idaniko varos wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 10:17

Great, thanks for sharing this blog article.Really thank you! Great.

free instagram followers wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 10:46

Appreciate you sharing, great article post.Really thank you! Awesome.

usa facebook fans wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 11:57

Thank you ever so for you article post.Thanks Again. Cool.

Cell phone service wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 12:41

Very good blog article. Keep writing.

extra income wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 13:50

Major thankies for the article post.Much thanks again. Cool.

how to lose thigh fat wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 16:31

Hey, thanks for the blog post.Really thank you! Great.

jailbreak iphone 6 wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 18:26

Looking forward to reading more. Great blog post.Thanks Again. Really Great.

Tanika Vanburen wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Wed, Feb 27 2013 23:36

Thanks again for the article post.Much thanks again. Want more.

wooden hot tubs wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Thu, Feb 28 2013 7:39

Thanks so much for the article. Really Cool.

Vpn wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Thu, Feb 28 2013 20:31

Very good blog article.Really thank you!

ourmeds wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Thu, Feb 28 2013 22:07

wow, awesome post.

Ucak Bileti|Ucak Bileti wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Fri, Mar 1 2013 12:16

I am so grateful for your blog.Thanks Again. Will read on...

GeForce GTX 690 wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Fri, Mar 1 2013 12:32

Great, thanks for sharing this blog article.Much thanks again. Will read on...

sexkontakt per sms wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Fri, Mar 1 2013 13:06

I really liked your post.Really looking forward to read more. Much obliged.

london escorts wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Fri, Mar 1 2013 14:08

Im grateful for the blog article.Really thank you! Really Great.

foc de artificii wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Fri, Mar 1 2013 14:20

I value the blog.Much thanks again.

art galleries in mumbai wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Fri, Mar 1 2013 15:09

Im grateful for the blog.Really looking forward to read more. Awesome.

adjustable dumbbell review wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Fri, Mar 1 2013 15:43

A big thank you for your blog.Thanks Again. Great.

web content writer wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Fri, Mar 1 2013 17:13

I really like and appreciate your blog.Really looking forward to read more. Really Cool.

daily steals wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Fri, Mar 1 2013 17:19

Im obliged for the blog post.Really looking forward to read more. Really Cool.

affiliate marketing|make 100 dollars a day wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Fri, Mar 1 2013 18:54

Awesome blog post. Will read on...

dublin pass discount wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Fri, Mar 1 2013 18:57

Appreciate you sharing, great article. Keep writing.

ekg blog wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Fri, Mar 1 2013 20:43

Appreciate you sharing, great article post. Will read on...

Multilevell marketing wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Fri, Mar 1 2013 21:24

Looking forward to reading more. Great post. Will read on...

youtube wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Fri, Mar 1 2013 22:05

I truly appreciate this blog.Thanks Again. Fantastic.

Ferienwohnung cuxhaven wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Fri, Mar 1 2013 22:25

Thanks-a-mundo for the article post.Thanks Again. Great.

halovar wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sat, Mar 2 2013 0:09

Major thanks for the article post.Much thanks again. Want more.

oxyelite pro wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sat, Mar 2 2013 1:52

Really appreciate you sharing this article.Thanks Again.

best seo link wheel services wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sat, Mar 2 2013 2:15

Muchos Gracias for your article post.Much thanks again. Fantastic.

lipo 6 wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sat, Mar 2 2013 3:36

wow, awesome article post.Really looking forward to read more. Will read on...

how to blog wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sat, Mar 2 2013 5:20

I value the blog. Awesome.

full downloads wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sat, Mar 2 2013 5:44

Enjoyed every bit of your blog.

car insurance wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sat, Mar 2 2013 7:04

A big thank you for your article post.Much thanks again. Really Cool.

90 Day Payday Loans wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sat, Mar 2 2013 8:48

I am so grateful for your article.Much thanks again. Keep writing.

personal injury attorney houston wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sat, Mar 2 2013 9:56

Im grateful for the article.Really thank you! Awesome.

seo services adelaide wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sat, Mar 2 2013 10:34

Muchos Gracias for your blog.Much thanks again. Keep writing.

kim kardashian sex tape wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sat, Mar 2 2013 12:03

I truly appreciate this blog post.Really looking forward to read more. Want more.

gold buyers wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sat, Mar 2 2013 12:22

Thanks for sharing, this is a fantastic article.Much thanks again. Keep writing.

Get Twitter followers wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sat, Mar 2 2013 13:03

Really enjoyed this blog article. Will read on...

pure green coffee bean extract max wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sat, Mar 2 2013 14:08

Thanks-a-mundo for the blog article.Really thank you! Really Great.

Creative Domain Names wrote re: VS 2010 Package Development – Chapter 1: Visual Studio Packages
on Sat, Mar 2 2013 14:41

Thanks for the blog post. Really Great.

bing.com wrote bing.com
on Mon, Oct 6 2014 19:23

VS 2010 Package Development – Chapter 1: Visual Studio Packages - DiveDeeper's blog - Dotneteers.net

Business Plan Template Word wrote Business Plan Template Word
on Sat, Oct 11 2014 14:22

VS 2010 Package Development – Chapter 1: Visual Studio Packages - DiveDeeper's blog - Dotneteers.net

Blitz Brigade Hack Tool wrote Blitz Brigade Hack Tool
on Fri, Oct 17 2014 21:43

VS 2010 Package Development – Chapter 1: Visual Studio Packages - DiveDeeper's blog - Dotneteers.net

Pac-Man Friends Hack wrote Pac-Man Friends Hack
on Sat, Oct 25 2014 5:03

VS 2010 Package Development – Chapter 1: Visual Studio Packages - DiveDeeper's blog - Dotneteers.net