DiveDeeper's blog

VS 2010 Package Development – Chapter 1: Visual Studio Packages

2010-03-02T12:13:03Z

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

 using System;
using System.ComponentModel.Design;
using System.Diagnostics;
using System.Globalization;
using System.Runtime.InteropServices;
using Microsoft.VisualStudio.Shell;
using Microsoft.VisualStudio.Shell.Interop;
 
namespace DeepDiver.FirstLook
{
  [PackageRegistration(UseManagedResourcesOnly = true)]
  [InstalledProductRegistration("#110", "#112", "1.0", IconResourceID = 400)]
  [ProvideMenuResource("Menus.ctmenu", 1)]
  [Guid(GuidList.guidFirstLookPkgString)]
  public sealed class FirstLookPackage : Package
  {
    public FirstLookPackage()
    {
      Trace.WriteLine(string.Format(CultureInfo.CurrentCulture, "Entering constructor for: {0}", this.ToString()));
    }
 
    protected override void Initialize()
    {
      Trace.WriteLine(string.Format(CultureInfo.CurrentCulture, "Entering Initialize() of: {0}", this.ToString()));
      base.Initialize();
 
      // Add our command handlers for menu (commands must exist in the .vsct file)
      OleMenuCommandService mcs = GetService(typeof(IMenuCommandService)) as OleMenuCommandService;
      if (null != mcs)
      {
        // Create the command for the menu item.
        CommandID menuCommandID = new CommandID(GuidList.guidFirstLookCmdSet, (int)PkgCmdIDList.cmdidShowMyMessage);
        MenuCommand menuItem = new MenuCommand(MenuItemCallback, menuCommandID);
        mcs.AddCommand(menuItem);
      }
    }
 
    private void MenuItemCallback(object sender, EventArgs e)
    {
      // Show a Message Box to prove we were here
      IVsUIShell uiShell = (IVsUIShell)GetService(typeof(SVsUIShell));
      Guid clsid = Guid.Empty;
      int result;
      Microsoft.VisualStudio.ErrorHandler.ThrowOnFailure(uiShell.ShowMessageBox(
                 0,
                 ref clsid,
                 "FirstLook",
                 string.Format(CultureInfo.CurrentCulture, "Inside {0}.MenuItemCallback()", this.ToString()),
                 string.Empty,
                 0,
                 OLEMSGBUTTON.OLEMSGBUTTON_OK,
                 OLEMSGDEFBUTTON.OLEMSGDEFBUTTON_FIRST,
                 OLEMSGICON.OLEMSGICON_INFO,
                 0,        // false
                 out result));
    }
  }
}
 

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:

 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:

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

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:

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

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

 <?xml version="1.0" encoding="utf-8"?>
<CommandTable xmlns="http://schemas.microsoft.com/VisualStudio/2005-10-18/CommandTable" 
              xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <Extern href="stdidcmd.h"/>
  <Extern href="vsshlids.h"/>
  <Extern href="msobtnid.h"/>
 
  <Commands package="guidFirstLookPkg">
    <Groups>
      <Group guid="guidFirstLookCmdSet" id="MyMenuGroup" priority="0x0600">
        <Parent guid="guidSHLMainMenu" id="IDM_VS_MENU_TOOLS"/>
      </Group>
    </Groups>
 
    <Buttons>
      <Button guid="guidFirstLookCmdSet" id="cmdidShowMyMessage" priority="0x0100" type="Button">
        <Parent guid="guidFirstLookCmdSet" id="MyMenuGroup" />
        <Icon guid="guidImages" id="bmpPic1" />
        <Strings>
          <CommandName>cmdidShowMyMessage</CommandName>
          <ButtonText>Simple Message</ButtonText>
        </Strings>
      </Button>
    </Buttons>
   
    <Bitmaps>
      <Bitmap guid="guidImages" href="Resources\Images_32bit.bmp" usedList="bmpPic1, bmpPic2, bmpPicSearch, bmpPicX, bmpPicArrows"/>
    </Bitmaps>
  </Commands>
 
  <Symbols>
    <GuidSymbol name="guidFirstLookPkg" value="{d55758eb-6581-48fe-930b-f3536f43b6f0}" />
    <GuidSymbol name="guidFirstLookCmdSet" value="{05da2180-8d8e-4822-913b-b6a9012c4b2b}">
      <IDSymbol name="MyMenuGroup" value="0x1020" />
      <IDSymbol name="cmdidShowMyMessage" value="0x0100" />
    </GuidSymbol>
    <GuidSymbol name="guidImages" value="{49ba23b3-1631-483d-a095-003cb157f55d}" >
      <IDSymbol name="bmpPic1" value="1" />
      <IDSymbol name="bmpPic2" value="2" />
      <IDSymbol name="bmpPicSearch" value="3" />
      <IDSymbol name="bmpPicX" value="4" />
      <IDSymbol name="bmpPicArrows" value="5" />
    </GuidSymbol>
  </Symbols>
 
</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:

 [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.

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:

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

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.

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.

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.

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.

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

 <?xml version="1.0" encoding="utf-8"?>
<Vsix Version="1.0.0" xmlns="http://schemas.microsoft.com/developer/vsx-schema/2010">
  <Identifier Id="d55758eb-6581-48fe-930b-f3536f43b6f0">
    <Name>FirstLook</Name>
    <Author>DeepDiver</Author>
    <Version>1.0</Version>
    <Description xml:space="preserve">Demonstrates the basic VSPackage concepts</Description>
    <Locale>1033</Locale>
    <InstalledByMsi>false</InstalledByMsi>
    <SupportedProducts>
      <VisualStudio Version="10.0">
        <Edition>Pro</Edition>
      </VisualStudio>
    </SupportedProducts>
    <SupportedFrameworkRuntimeEdition MinVersion="4.0" MaxVersion="4.0" />
  </Identifier>
  <References>
  </References>
  <Content>
    <VsPackage>|FirstLook;PkgdefProjectOutputGroup|</VsPackage>
  </Content>
</Vsix>
 
 

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

 [$RootKey$\InstalledProducts\FirstLookPackage]
@="#110"
"Package"="{d55758eb-6581-48fe-930b-f3536f43b6f0}"
"PID"="1.0"
"ProductDetails"="#112"
"LogoID"="#400"
[$RootKey$\Packages\{d55758eb-6581-48fe-930b-f3536f43b6f0}]
@="DeepDiver.FirstLook.FirstLookPackage, FirstLook, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8e5c6425e9b83cf4"
"InprocServer32"="$WinDir$\SYSTEM32\MSCOREE.DLL"
"Class"="DeepDiver.FirstLook.FirstLookPackage"
"CodeBase"="$PackageFolder$\FirstLook.dll"
[$RootKey$\Menus]
"{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.

VS 2010 and .NET 4 Six-In-One: My last chapter submitted today…

2009-12-22T13:08:53Z

A few weeks ago I shared the news with you that the Dotneteers team works on a book with an authoring team including other community members. Today I submitted my last (seventh) chapter dealing with the core enhancements of the .NET 4.0 Framework. The book is available on Amazon you can already preorder it. Visual Studio 2010 and .NET 4 Six-In-One will be published around Visual Studio 2010 launch time. Here is the short table of contents:

Chapter 1: History of Visual Studio and Current Editions
Chapter 2: VS UI Enhancements
Chapter 3: Visual Studio Snippets
Chapter 4: Visual Studio Templates
Chapter 5: Getting the most out of the IDE
Chapter 6: Extending Visual Studio
Chapter 7: .NET Framework Version History
Chapter 8: Window Presentation Foundation WPF
Chapter 9: Windows Communication Foundation
Chapter 10: Enhancements to the .NET Core Framework
Chapter 11: Enhancements to the .NET Workflow Framework
Chapter 12: Enhancements to the .NET Data Framework
Chapter 13: Enhancements to the .NET Communication Framework
Chapter 14: Enhancements to the .NET Client Framework
Chapter 15: .NET Charting Components
Chapter 16: ASP.NET Version History
Chapter 17: ASP.NET Charting Controls
Chapter 18: ASP.NET Dynamic Data
Chapter 19: ASP.NET MVC
Chapter 20: ASP.NET Ajax Improvements
Chapter 21: Ajax Control Toolkit, jQuery and More
Chapter 22: Visual Basic History
Chapter 23: Visual Basic 10 Language Improvements
Chapter 24: C# History
Chapter 25: C# 4 Language Improvements
Chapter 26: Other .NET Languages

However the book focuses on new features in VS 2010 and .NET 4, even those who use .NET 1.1 or VS 2005 right now may find it useful.

In the next few weeks you can read more details of the book, so stay tuned!

PDC 2009 Keynote – Tuesday

2009-11-17T15:52:08Z

After 2008 Microsoft organized a PDC again without waiting for two or more years, as it usually happened in the past. Right now I’m setting here in the main auditorium of Los Angeles Convention Center and watching this years keynote. Well, people around my typing on their notebooks, writing their blogs or twitting about what they see and hear.

Yesterday the first new thing happened, even before any official announcement, Microsoft Office 2010 Beta went to the MSDN Download Center. I’ve already started downloading it…

A short summary about what kind of messages I’ve got during this keynote:

Ray Ozzie, Chief Software Architect

Windows Azure: One coherent model using Windows Server and System Center. Tools for developers: Windows Azure tools for Java and Eclipse, PHP application support

Guest: Matt Mullenweg, Automaitc, manufacturer of WordPress:

Now WordPress works on Azure (oddlyspecific.com as one example)

Guest: Loic LeMear, Seesmic

Created Silverlight prototype for a new Twitter browser. Easy to use with user lists, custom-defined columns. They are going to create a platform around this app allowing plug-in development.

Ray Ozzie, Chief Software Architect

Announcement: Microsoft PinPoint for finding online Sharepoint and Exchange applications and other solutions
Announcment: Microsoft Codename “Dallas” CTP, creating a uniform access and discovery for data, Data-as-a-Service

Don Box, Chriss Sells:

C++ code runs on Windows Azure, they demonstrated it.
SQL Azure is easy, SQL Management Studio 2008 R2 supports it.

Bob Muglia, President, Server and Tools Business

Announcement: Your enterprise services connected to Windows Azure, code name “Project Sydney”
Announcement: Windows Azure Virtual Machine Role
Announcement: Windows Azure AppFabric (Caching, Workflow Hosting, Monitoring)
Announcement: Windows Identity Foundation RTM

Cameron Skinner:

Demos Azure development support with VS 2010 (AppFabric, WIF)

If you can, watch the PDC Keynote video you can access from here.

Visual Studio 2010 Beta2: Nice logo with no accessibility respect?

2009-10-22T20:59:16Z

I really like the new sexy design of MSDN and Visual Studio, both colors and form. The new logo suggests me that now Visual Studio is not a tool that roughly integrates separate development assets but rather a really integrated and uniform development tool for .NET. There are places where the logo is very impressive and looks really great, let me show a few:

However, the nice Möbius strip does not look nice on the Windows 7 taskbar:

Compared to the light shape of the Visual Studio 2008 icon, the new one is modest, but the biggest issue is that you can hardly recognize it is there. The situation is a bit better when VS 2010 is started, the lighter background helps a bit:

However, when you compare it to the VS 2008 icon, you can see, it is far away from being great and highlighted.

I would not say that this logo intentionally is bad from accessibility point of view, I rather suspect, the designer (or anyone else) never tried it using over a dark background like the Windows 7 taskbar. I’m not a designer or a UX person, but I guess adding a white border around the icon would help a lot.

DevTools Ecosystem Summit: Best Practices for Extending the IDE with a Focus on Performance, Part 3

2009-10-22T15:19:59Z

<Part 2

In the last section of my presentation I would like to show you common mistakes or pitfalls, and try to give you a few tips to cope with them.

One of the most difficult issues to solve is when package load failures occur. The main reasons why these issues occur are generally

exceptions in Initialize or
Loading failure of a referenced assembly, generally because the assembly is not on the probing path of Visual Studio.

This kind of errors are very annoying, because prevent any functions of our package working. Because packages are loaded on-demand by default, we can face package initialization issues unexpectedly.

VS 2008 does not leverages on WPF technology. With VS 2010 you can compile packages using WPF tool windows successfully, but when you try to show them, their caption is visible but the client area does not show up.

The Visual Studio Command Table files (.vsct) also can have traps you can walk into. You can easily write a VSCT that compiles well, but does not show up your commands, because it has some semantic issues.

I also would like to show you, how you can trace your packages to get some diagnostic information for troubleshooting.

Let’s start to walk into a few traps…

I modify the Initialize method of the CSharpStats package so that it tries to use a service before that service has been initialized, and so causes a NullReferenceException.

 protected override void Initialize()
{
  base.Initialize();
 
  // --- This will fail:
  var csharpSrv = GetService(typeof(SCSharpStats)) as ICSharpStats;
  csharpSrv.GetCSharpFiles();
 
  // --- Proffer the service instance
  var serviceContainer = this as IServiceContainer;
  serviceContainer.AddService(typeof(SCSharpStats), new CSharpStatsService(), true);
 

When we build and run the package and want to display the C# Statistics window, we have a package load failure message:

With the help of the debugger you can find the source of this error. Answering with Yes to this question means that you will see the error message continuously when Visual Studio tries to load your package. However clicking on now will suppress this message and what we see is only that tool window does not show up. We do not see that it is a package load failure! Start the package with debugging to catch the source of the issue!

The debugger stops at the code line raising an exception, and we can see which code line is responsible to prevent our package load. However, we are not also as lucky as in this case. Visual Studio has a so-called activity log where VS puts diagnostics messages. This log is turned off by default, but you can turn it on with the /log command line switch. To debug your package with the Experimental Instance, you have to change your project’s debug properties:

When running our faulty package again, we can look into the log file. This file can be found under your roaming profile in the Microsoft\VisualStudio\10.0Exp folder. In this file we can see that our package failed to load.

We can put our own messages into the activity log, CSharpStats also does it at the end of the Initialize method:

   var refreshCommandID = new CommandID(GuidList.guidCSharpStatsCmdSet,
    (int)PkgCmdIDList.cmdidRefreshCSharpStats);
  var menuRefresh = new MenuCommand(RefreshStats, refreshCommandID);
  mcs.AddCommand(menuRefresh);
  
  // --- Log initialization success
  ActivityLog.Write("CSharpStats", "Package initialization done.");
}
 

Now, when we delete the two fake lines preventing our package to load, and run the package again, the activity log shows our package gets loaded.

You can also discover messages the C# Statistics tool window put into the log.

Now, let’s examine a new potential issue that is new in VS 2010, and it is related to WPF tool windows. You can put semantic mistakes into the XAML definition of your tool window so that your project compiles, but the tool window does not work. I show you what phenomena escort this issue. Let’s put a semantic mistake into our tool window definition:

 <DataGridTextColumn Header="Types" Binding="{Binding Types}" 
                    Width="Auto" IsReadOnly="True" 
                    ElementStyle="{StaticResource QNumericCellStyle}" />
 

Here, I changed the NumericCellStyle static resource name to QNumericCellStyle, which is faulty, as there is no such static resource. Despite of this change, our package will compile. When the tool window is about to show, we can meet with two kind of behavior. If the tool window was persisted before, when it is to be displayed at Visual Studio startup time, we can see the frame of the window, but its client area is hidden:

When the tool window is not persisted, at creation time we get the following message:

Fortunately, debugging will help to find out what the reason of this message is. Start the Experimental hive in debug mode and try to display the tool window. The exception caught helps you to discover that actually creating the window pane control fails:

Well, this message helps to discover the location of the failure but not its cause. Click on the View Detail link in the exception popup and you’ll be wiser:

This message tells that the problem is the name of the static resource we try to use.

The VSCT files also are sources of similar issues. The VSCT compiler checks the syntax and does a few semantic checks, however, does not check all things that actually could be checked at compile time. When the VSCT file is merged with the Visual Studio menus, further checks are done, and faulty commands or UI elements are simply not merged into the VS menu. However, there are checks that occur only at runtime.

So, when our VSCT file has some semantic errors, it could lead to unexpected issues. Let me show one of them. I modify the VSCT file so, that the refresh button of the tool window tool bar is parented directly in the <Menu> item representing the tool bar and not in the <Group> element that is the logical container for the Refresh button. The original definition is:

 <Button guid="guidCSharpStatsCmdSet" id="cmdidRefreshCSharpStats"
  priority="0x0100" type="Button">
  <Parent guid="guidCSharpStatsCmdSet" id="RefreshToolbarGroup"/>
  <Icon guid="guidOfficeIcon" id="msotcidRefresh" />
  <Strings>
    <CommandName>RefreshProcessList</CommandName>
    <ButtonText>Refresh Process List</ButtonText>
  </Strings>
</Button>
 

I change it to:

 <Button guid="guidCSharpStatsCmdSet" id="cmdidRefreshCSharpStats"
  priority="0x0100" type="Button">
  <!-- I've changed the parent id -->
  <Parent guid="guidCSharpStatsCmdSet" id="CSharpStatsToolbar"/>
  <Icon guid="guidOfficeIcon" id="msotcidRefresh" />
  <Strings>
    <CommandName>RefreshProcessList</CommandName>
    <ButtonText>Refresh Process List</ButtonText>
  </Strings>
</Button>
 

This is a semantic error, the VSCT compiler does not show any error, so we can run our package. However, when we want to display the tool window, we get the following message:

When we try to display the window second time, we face with another message:

Just as before, we can turn to our good friend, to the debugger. Let’s start the package in debug mode and see where it breaks!

As you see, it breaks in the ShowToolWindow method when calling the FindToolWindow method, so the exception is thrown in a method that is within the Managed Package Framework. This kind of exception at the point is thrown when the shell is about putting together the window frame, the window pane and the related toolbars. By my experience, generally this message means that your VSCT file has issues, like the one I put in the file above.

As a summary of the presentation, I would like to summarize my main messages on this slide. I would encourage you to leverage on WPF and MEF as they are great technologies helping you writing your extensions for VS 2010.

To be frugal or let’s say conservative with resource consumption, be lazy with loading your components and objects owned by your component.

Keep your UI always responsive and used idle loading wherever it is possible.

In order to cope with common package mistakes, use techniques helping to recognize while your packages fail.

Thank you for your attention!

DevTools Ecosystem Summit: Deploying Visual Studio 2010 Extensions, Part 2

2009-10-20T22:23:32Z

<Part1

[Quan] Istvan is now going to show you how to create an extension and how to publish it to the Visual Studio gallery.

[Istvan] In this demo I will create a simple package with a Nice Tool Window. I have installed Visual Studio SDK on my machine, and now I create this package using a Visual Studio Package. I go to File|New|Project and select the Visual Studio Integration Package template to start a new project.

I name my projects to NiceToolWindow and click OK. The VSPackage template launches the Visual Studio Integration Package Wizard with the following Welcome page:

In the first page I declare that I want to create a C# package.

The second page collects a few information about my package used for code generation and displaying branding information.

I declare that I want to create only a Tool window this time:

I specify the name for my tool window and set the ID to be used for the command showing up it.

On the last wizard page I clear the checkboxes, because for this demo I do not want any test projects to be generated.

As you see, the wizard creates the code in a few seconds. I can immediately build and run it. By pressing Ctrl+F5 a new Visual Studio instance is started. As you see from its title, it is called “Visual Studio Experimental Instance”. This runs exactly the same devenv.exe as our main instance, but uses a separate set of configuration settings. This instance works as a test bed for the package.

Our nice tool can be accessed by using the View|Other Windows|Nice Tool Window command. It displays the tool window, and as we click on the button it pops up a message indicating that it really works!

Now I close the Experimental instance and go back to the source code generated.

When I ran the package, it was deployed for the Experimental Instance with VSIX. The key of the deployment is the source.extension.vsixmanifest file as you see it here in the Solution Explorer.

This file contains all the information used to create the deployment package just as Quan mentioned. When I open it, a new designer displays the content of the manifest. This time in Beta2 this design surface does not seem very polished:

Instead, I use the code view, as the VSIX file is actually an XML file, and you can recognize the the sections representing the information Quan talked about:

The package is identified by its Id and Version, and it has a few set of display attributes. This manifest tells that the extension is supported by the Professional edition of Visual Studio. The VSPackage element in the Content section tells that our extension is a Visual Studio package. The |NiceToolWindow;PkgdefProjectOutput| token provides the information the build process uses to set up the list of artifacts to be included in the deployment kit.

Let’s build our package, and see what is within the .vsix file we get! Because the .vsix file is a zip archive conforming with the Open Packaging Convention, we can rename it to .zip, open it to look what’s inside:

We can see that the NiceToolWindow.dll encapsulation our package is there and also we see a file with the name NiceToolWindow.pkgdef. This latter one contains the registry settings required to register our package which is a COM component.

 [$RootKey$\InstalledProducts\NiceToolWindowPackage]
@="#110"
"Package"="{6617051f-7e5c-41b6-9f62-8221d1cfc372}"
"PID"="1.0"
"ProductDetails"="#112"
"LogoID"="#400"
[$RootKey$\Packages\{6617051f-7e5c-41b6-9f62-8221d1cfc372}]
@="DiveDeeper.NiceToolWindow.NiceToolWindowPackage, NiceToolWindow, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6c8545f2ca1aeabb"
"InprocServer32"="$WinDir$\SYSTEM32\MSCOREE.DLL"
"Class"="DiveDeeper.NiceToolWindow.NiceToolWindowPackage"
"CodeBase"="$PackageFolder$\NiceToolWindow.dll"
[$RootKey$\Menus]
"{6617051f-7e5c-41b6-9f62-8221d1cfc372}"=", Menus.ctmenu, 1"
[$RootKey$\ToolWindows\{65f23b5e-328d-40f0-9963-59916b77368d}]
@="{6617051f-7e5c-41b6-9f62-8221d1cfc372}"
"Name"="DiveDeeper.NiceToolWindow.MyToolWindow"
 

In the past with VS 2008 the settings in this file were used to create the MSI installation kit, and had to be put into the install kit in order the package could be registered during setup time. There’s no need to do it anymore! The VSIX installer will extract this information form the zip archive and Visual Studio will use it at the next startup to register the package.

Now, we have seen how our nice tool window’s deployment package has been created. We are going to share this component with the community through Visual Studio Gallery. We can access the gallery with the http://www.visualstudiogallery.com URL.

The most important button to share our NiceToolWindow is the Upload button just right below the search text box. Before starting the sharing process, I would like to give you a very short guided tour around the gallery.

You can use the departments under Categories to look for a specific type of component. For example, opening the Tools department and then selecting Coding, you get a list of components related to coding tasks.

Under categories you can filter the components by Visual Studio versions. Select Visual Studio 2010 to see which coding tools work with VS 2010:

You can also filter by cost category. When you click on “Free” you’ll see only free coding components working with VS 2010.

Clicking on a components directs you to the details page where you can immediately download and install the component.

So, let’s go back to our original idea, and upload the NiceToolWindow package to the gallery. It contains three easy steps that start with clicking on the Upload button. In order to upload components, you must sign in. The first step is selecting the type of extension. In our case it is a tool.

The next step is to decide how we want to upload the component:

We can select from two options. We could take the first option to allow community members download it directly from the gallery. In this case the component detail page will display a “Download” button. The second option lets us specify a link to redirect members to another page where we can manage the whole download/purchase process. In this case the component detail page will display a “Get now” button.

I have selected the first option, because I want to share a free component, and I also selected the NiceToolWindow.vsix file to upload. When I click the Next button, the .vsix file is uploaded and you can specify a few more attributes to categorize your component, and also can add a rich text description to it.

Before going on, you I to accept the contribution agreement…

and my component is ready to be published:

At this point I can click on the “publish” link to allow gallery visitors to browse and download NiceToolWindow, as you see it is at the top of the list of recently added components.

Now, I put the cap of a community member on my hat to show you how easy is to find and download the uploaded component. I open Visual Studio 2010 and start Extension manager. Because I’m looking for a “nice tool” I type “Nice” in the search box.

The simple tool we have just uploaded is on the list! When I click on download, install it, it goes into my Installed Extensions tab.

After restarting Visual Studio, this “great” tool can be immediately started. If I do not like it, I can click on the Uninstall button to remove it.

I hope you’ve liked it, and I whet your appetite to share extensions!

[Quan] Now that you’ve seen how easy it is to build and deploy an extension, we want you to start building and sharing extensions with the whole world!

In case you ship something and need to make changes later on, we provide a simple update model that removes the existing extension and lays down a new one. All you need to do is specify the same VSIX ID – the unique identifier and a newer version. Then upload it to the gallery and customers who have the old version can download your update.

So, hopefully we’ve sold you on how cool xcopy deployment is. It’s so simple, a caveman can do it.

However, xcopy does have limitations which I do want to call out.

We don’t write to the registry outside of the VS hive. To write to the registry, you can use a pkgdef file. However, that’s limited to the VS Hive. Writing keys for anything else, including file associations into HK Classes Root is not supported. Other things not supported are start menu and desktop shortcuts, framework functionality such as creating Native Images or adding files to the Global Assembly Cache. Lastly, this is xcopy. Install is copy or unzip. Uninstall is delete the folder. We don’t support custom actions.

If you’re installing a database extension and need to configure your back end SQL Server database, use an MSI.

If you extension is completely inside the VS world, VSIX works well and is the recommended extension deployment technology for VS 2010. If you need to install or configure things outside of VS, we still support MSI installs. The in product experience will show the MSIs that are uploaded to the VS Gallery however acquiring them will take the user to the landing page in IE where they can download and install the MSI.

To make sure your extension appears in the list of installed extensions in the Extension Manager, make sure your MSI installs a VSIX manifest and sets the InstalledByMSI element to true. The payload will also need to be installed to the VSInstallDir\Common7\IDE\Extensions directory.

If you have registry keys under the VS Hive or packages that need to be registered, use a pkgdef file. Also, there shouldn’t be a need for you to call devenv.exe /setup for VS 2010.

The end user will be able to see your extension installed however, they will still need to go to Windows Add/Remove programs to remove it.

We threw a lot at you today. So, now that you’ve got all this knowledge, go download and install VS 2010 and the SDK, then start building extensions and sharing them on the VS gallery!

And with that final note, we’re done with our deploying VS extensions talk.

Thank you for your time. I hope we’ve got you excited about the extension manager and how easy it is to share your extensions!

DevTools Ecosystem Summit: Deploying Visual Studio 2010 Extensions, Part 1

2009-10-20T18:28:29Z

I had the opportunity to present at the DevTools Ecocsystem Summit held in Redmond between October 19 and 23. I had two presentations, the first with the title “Best Practices for Extending the IDE with a Focus on Performance”, and the second held in cooperation with Quan To with the title of “Deploying Visual Studio 2010 Extensions”.

After the presentations I decided to blog the presentations in a transcript-like way including demos with source code and screenshots.

This post is the first part of the “Extension Deployment” presentation held together with Quan.

[Quan] Good Aftenoon! Welcome to the Deploying Visual Studio 2010 Extensions session! I’m Quan To, a program manager on the Visual Studio Platform team. My partner for this talk is Istvan Novak, one of our VSX MVPs and an expert in extending Visual Studio.

I’ve spent 3 years as the Visual Studio Deployment Program Manager prior to joining the platform team and even though I know MSI pretty well, it’s still hard to deploy a VS extension!

There’s already a lot to know when building an extension. Why do you need to learn even more stuff and all the nuisances about deploying an extension? Everyone knows creating an MSI is hard. You need to learn MSI, buy install shield or spend some time learning Wix, then search for which registry keys you need to write for VS to find your extension, and hope everything works when you build your setup.

Setup is painful. Instead of having these experiences when deploying your extensions…

We want you to make you happy, happy, happy!

I’m going to hand things over to Istvan who is going to show you our cool new deployment and acquisition experience we built into VS 2010.

[Istvan] Good Afternoon! It is great to be here on this Summit and see that so many attendees cannot be seduced by the other track!

In this demo I will show you one of my favorite features in the new Visual Studio release, namely Extension Manager and the related user experience. I can easily access the Extension manager from the Tools menu or from the toolbar by clicking on this Tetris-like button.

When this window opens up you immediately see the extensions already installed that can be templates or tools. This time I have only the Power Commands tool installed. There are two nice tabs in the left pane. By clicking on the Online Gallery tab you start browsing the components available in Visual Studio Gallery. The list is created in a few seconds and when you select an item in it, the related description is displayed in the right pane.

Well, I’m searching for a tool that could help me in navigating through my source code files. Let’s try to search for the word “source” and look if I can find a tool like that…

There are many tools having the word “source” somewhere in their description… Here is one named Source Outliner! It’s description suggests that it may the tool I’m looking for! I click on the Download button and Extension manager immediately starts downloading the extension.

I Click on install signing I accept the licence agreement. The tool installs in a second, and appears in the Installed Extensions tab immediately.

As you can see from the message at the bottom of the dialog, installing a tool requires a Visual Studio restart. I do not want to go into details why this restart it is necessary, and please believe me, it is not because the VS team is lazy and simply did not want to implement some features to avoid the restart. This has more deep architecture reasons. Restarting VS is not painful. The IDE returns back to the state where you left it before, and also loads your recent solution. As you see it is quite quick.

Now, I can use the View|Other Windows|Source Outliner Power Toy command to display this tool. I “dogfood” it by opening its source and selecting the CodeOutlineFileManager.cs file for further examination. When I click a member in the tool window, the corresponding code is marked in the source file window.

I like this tool! If I did not like it, I could uninstall it from Extension Manager simply selecting this tool from the Installed Extensions tab, and clicking on Uninstall. Just as when I installed the tool, I have to restart Visual Studio to finish removing it.

I hope, now you can understand why it is one my favorite features.

[Quan] As Istvan mentioned, the backend to the Extension Manager is the Visual Studio Gallery. Some of you may know that we launched the Visual Studio Gallery back in VS 2008. In less than 2 years, we have over 1200 extensions on the gallery! As a side note, we surpassed our competition a month ago J

Some other notable changes we made to the gallery include moving to be a part of MSDN, the UI and navigation, we’ve improved the ratings and reviews, added things like notifications and statistics, and web services for the extension manager to talk to. The other big thing we now provide is a place to host your extension. Instead of just reference links, you now have the option to post your extension bits on the gallery.

I’m going to walk you through the Extension Manager architecture to show you the flow of an extension through the system.

We start with Visual Studio and the new Extension Manager service. This service will talk to the online gallery and handle downloading, installing, uninstalling, enabling, disabling, and querying of extensions.

Within Visual Studio, there are extension manager clients that talk to the Extension Manager Service. This includes the Extension Manager UI, the New Project Dialog, and even the Start Page talks to the extension manager.

The clients ask the extension manager for a list of extensions that can be downloaded and installed. The Extension manager queries the gallery and returns a list of extensions. The client then tells the extension manager which extension to install and the file gets downloaded onto the user’s machine. The extension then gets installed to a per user or per machine location.

The unit of deployment here is this purple box which we call a V-SIX or V.S.I.X.

The VSIX file is a renamed zip file. It’s our mechanism for packaging up an xcopy deployable extension. The VSIX contains two main parts, your payload and the manifest.

The VSIX manifest file contains three distinct parts. The first is the metadata about your extension including the name, company, version, license and icons. The second part allows you to declare dependencies on other VSIX files. If those aren’t installed on the machine, you won’t be able to install your VSIX. We also have a notion of nested VSIXes which means you can carry your dependency in your payload and have that installed first.

The third part is the content section which specifies the key content parts of your extension.

For VS 2010, we support several types of content. These include VS Packages, MEF Components, Project and item Templates, and Toolbox Controls. We also support custom types so if you build your own extensibility points, your own customers can extend your extension. Our custom start pages inside VS is an example of a custom type.

Things that didn’t make it as a supported VSIX type in Dev 10 are Addins and Snippets. We are hoping to add those in a future release of VS.

Part 2>

DevTools Ecosystem Summit: Best Practices for Extending the IDE with a Focus on Performance, Part 2

2009-10-20T12:25:11Z

<Part 1

After treating and demonstrating why is it beneficial to turn to WPF, let’s see how extensions can target better performance. I’d be able to talk about performance topics so much that I could take over all the session slots left for today or even for tomorrow… Instead of treating each of them, I collected a bunch of tips that gives you ideas what you can do with performance issues or how you can avoid them.

The key of providing a great performance can be described simply: Consume only the resources you really, really, really need. If possible, release unused resources and claim them when you need them again.

This approach starts with loading your package only when that is required and not before. By default the VS shell loads packages on-demand when the first command, UI, service or other package owned objects are about to be used. However, you can change this behavior by either loading explicitly your package with the IVsShell.LoadPackage method, or adding the ProvideAutoLoad attribute to your packages. This attribute provides that your package is automatically loaded when the Shell enters in a certain context, for example a solution is loaded, the build process started, and so on.

I suggest totally avoiding the LoadPackage approach.

You must use the ProvideAutoLoad attribute also wisely. If you use the so-called NoSolution context it causes the shell automatically load your package at VS startup time. This context is heavily overloaded and startup time is everyone’s concern. However, this is also broken in a few situations: for example when you run devenv.exe from a command line with a file or solution, your package does not get loaded. Be more selective with using this attribute.

If you are implementing tool windows, you can set the ProvideToolWindowVisibility attribute to display the tool window when the shell enters in a specific context. This time your package is loaded. When you create a tool window, the instance behind that is never destructed, even if you close the tool window. You can catch the event when tool windows are about to be hidden or shown and this can be used to release and then reallocate resources.

If your extension takes time to make some kind of processing be sure to write it so that the UI remain responsive. You can use some kind of background threading for provide this responsiveness or even you can leverage on using the CPU and other resources while Visual Studio is idle.

I think the concepts I have mentioned tell more if we try them in the practice. I have created a VSPackage to demonstrate how to use AutoProvideLoad attribute, what idle processing means and I also show how we can release and reallocate resources held by tool windows.

My package implements a tool window that parses all C# files in the active project and displays some useful statistics about them, for example, how many methods and statements they use. This package is far away from being functionally completed, but gives me good opportunity to demonstrate performance things. I also use this sample to show a few concepts and how it evolved to reach this state.

First I build this package and show how it will look like after applying all enhancements. When I open a solution, the C# Statistics tool window automatically appears and starts parsing C# files:

I used the ProvideToolWindowVisibility attribute and set it to the SolutionExist context to show the tool window automatically when a solution is opened:

 //[ProvideAutoLoad(GuidList.UICONTEXT_SolutionExists)]
[ProvideToolWindowVisibility(typeof(CSharpStatsToolWindow),
  GuidList.UICONTEXT_SolutionExists)]
 

This attribute takes two parameters. The first represents the type of the tool window we set the visibility options for, the second is the GUID of the UI context to bind the visibility of the window to. You can use this attribute for the same window type to set multiple UI contexts.

Should I used the ProvideAutoLoad attribute, the owner package would be loaded but the tool window would not be displayed.

Let’s debug the package and show how it works. I put a breakpoint into the Initialize method that is to be executed right after the package has been load by the shell, and start debugging it.

You see that Visual Studio has finished its startup, but the breakpoint have not yet reached. Now I open the C# solution in the Experimental Instance, and as you see, now the breakpoint has been reached signing that our package has been loaded.

Now, let’s change the context to FullScreen.

 [ProvideToolWindowVisibility(typeof(CSharpStatsToolWindow),
  GuidList.UICONTEXT_FullScreenMode)]
 

Running the application this time will show the tool window when we use the View|Full screen. As the full screen mode is left, the tool window is hidden again. This is exactly what ProvideToolWindowVisibility does. When entering into the context, the tool window is (created and) displayed, when leaving the context, the window is hidden.

Let’s set it back the attribute’s value to SolutionExists. Now I show you a few internals of the package and then demonstrate a few steps I have reached during application development. The implementation follows the Model-View-Controller pattern.

The C# parsing related functions are provided by the ICSharpStats service (Model interface), here you can see, how simple the service interface is:

 [Guid("99C37858-E1A7-468B-AC62-FBE842E25387")]
public interface ICSharpStats
{
  // ------------------------------------------------------------------------
  /// <summary>
  /// Collects all .cs files from the active project
  /// </summary>
  // ------------------------------------------------------------------------
  IEnumerable<string> GetCSharpFiles();
 
  // ------------------------------------------------------------------------
  /// <summary>
  /// Parses the specified file and collects C# info
  /// </summary>
  // ------------------------------------------------------------------------
  CSharpFileInfo ProcessFile(string fileName);
}
 

This service is implemented by the CSharpService class that plays the role of Model. It uses my own C# parser to collect information from C# files.

The UI of the application is provided by a WPF user control that really implements the View role in the MVC pattern, and does not handle any controller functions. The XAML definition of the UI is simple:

 <UserControl x:Class="DiveDeeper.CSharpStats.CSharpStatsControl"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
             mc:Ignorable="d" 
             d:DesignHeight="300" d:DesignWidth="300"
             Name="MyToolWindow"
             Background="{DynamicResource VsBrush.ToolWindowBackground}">
  <UserControl.Resources>
    <Style x:Key="ColumnHeaderStyle" TargetType="DataGridColumnHeader">
      <Setter Property="FontWeight" Value="SemiBold" />
    </Style>
    <Style x:Key="NumericCellStyle">
      <Setter Property="TextBlock.TextAlignment" Value="Right" />
    </Style>
  </UserControl.Resources>
  <DockPanel>
    <StackPanel Margin="4" DockPanel.Dock="Bottom" Orientation="Horizontal">
      <TextBlock Text="Remaining items: " />
      <TextBlock x:Name="RemainingLabel">0</TextBlock> 
    </StackPanel>
    <DataGrid Name="FileInfoGrid"
              AutoGenerateColumns="False" GridLinesVisibility="All" 
              HeadersVisibility="All" VerticalAlignment="Top" 
              VerticalContentAlignment="Top" VerticalScrollBarVisibility="Auto"
              ColumnHeaderStyle="{StaticResource ColumnHeaderStyle}" 
              BorderBrush="CadetBlue" 
              HorizontalGridLinesBrush="Gainsboro" VerticalGridLinesBrush="Gainsboro" 
              AlternatingRowBackground="Azure" AreRowDetailsFrozen="False" FontSize="14">
      <DataGrid.Columns>
        <DataGridTextColumn Header="File" Binding="{Binding FileName}" 
                            Width="Auto" IsReadOnly="True" FontWeight="SemiBold" 
                            Foreground="Maroon" />
        <DataGridTextColumn Header="Namespaces" Binding="{Binding Namespaces}" 
                            Width="Auto" IsReadOnly="True" 
                            ElementStyle="{StaticResource NumericCellStyle}"/>
        <DataGridTextColumn Header="Types" Binding="{Binding Types}" 
                            Width="Auto" IsReadOnly="True" 
                            ElementStyle="{StaticResource NumericCellStyle}" />
        <DataGridTextColumn Header="Nested Types" Binding="{Binding NestedTypes}" 
                            Width="Auto" IsReadOnly="True" 
                            ElementStyle="{StaticResource NumericCellStyle}"/>
        <DataGridTextColumn Header="Members" Binding="{Binding Members}" 
                            Width="Auto" IsReadOnly="True" 
                            ElementStyle="{StaticResource NumericCellStyle}"/>
        <DataGridTextColumn Header="Methods" Binding="{Binding Methods}" 
                            Width="Auto" IsReadOnly="True" 
                            ElementStyle="{StaticResource NumericCellStyle}"/>
        <DataGridTextColumn Header="Statements" Binding="{Binding Statements}" 
                            Width="Auto" IsReadOnly="True" 
                            ElementStyle="{StaticResource NumericCellStyle}"/>
        <DataGridTextColumn Header="Path" Binding="{Binding FilePath}" 
                            Width="*" IsReadOnly="True" />
      </DataGrid.Columns>
    </DataGrid>
  </DockPanel>
</UserControl>
 

The code behind of the UI illustrates the this user control is really used as a view, free from Controller functionality:

 public partial class CSharpStatsControl : UserControl
{
  // ------------------------------------------------------------------------
  /// <summary>
  /// Initializes the control
  /// </summary>
  // ------------------------------------------------------------------------
  public CSharpStatsControl()
  {
    InitializeComponent();
  }
 
  // ------------------------------------------------------------------------
  /// <summary>
  /// Sets the source of the data grid.
  /// </summary>
  // ------------------------------------------------------------------------
  public void SetItemsSource(IEnumerable<CSharpFileInfo> source)
  {
    FileInfoGrid.ItemsSource = source;
  }
 
  // ------------------------------------------------------------------------
  /// <summary>
  /// Sets the value of remaining items
  /// </summary>
  // ------------------------------------------------------------------------
  public void SetRemainingCount(int remainingCount)
  {
    RemainingLabel.Text = remainingCount.ToString();
  }
}
 

The lion’s share of the work is done by the CSharpStatsToolWindow class in the role of Controller.

I have built in a few flags into this class to help me show earlier states of the application. So let me show you what the first version of my package was from the user responsiveness point of view.

 // --- Constants and fields used for demonstration
const int Slowing = 1;
const int SleepTime = 20;
private int _IdleCounter;
private bool UseIdleProcessing = true;
private bool UseResourceSavings = true;
private bool UseAutoRefresh = true;
 

[Set the UseIdleProcessing flag to false and run the package. Show that opening a project stops UI responding about for 5 seconds.]

You see, it is not a “polite” behavior. The root issue is that parsing more than 400 C# files takes time. If it happens on the main UI thread, then it blocks any other activities. How this could be improved? Well we can use idle processing, make the work done while Visual Studio is idle.

I have made the following architectural changes in the controller:

Instead of processing the C# files, I put them into a queue. When the Shell is idle, it takes one file from the queue, parses it and then adds it to the to the collection used as an item source for the grid.
The item source of the grid is implemented as an ObservableCollection<>. When a file is processed and added to this collection, the UI is refreshed without any further coding.

 // --- List containing the processed C# items 
private ObservableCollection<CSharpFileInfo> _FileInfoCollection;
 
// --- Queue holding items for idle processing
private Queue<string> _FilesToProcess;
 

Preparing our tool window for idle processing requires registering it with OleComponentManager in the OnCreated method:

 // --- Set up Idle processing
var oleComponentManager = base.GetService(typeof(SOleComponentManager))
  as IOleComponentManager;
if (oleComponentManager != null)
{
  uint pwdId;
  OLECRINFO[] crinfo = new OLECRINFO[1];
  crinfo[0].cbSize = (uint)Marshal.SizeOf(typeof(OLECRINFO));
  crinfo[0].grfcrf = (uint)_OLECRF.olecrfNeedIdleTime |
                                (uint)_OLECRF.olecrfNeedPeriodicIdleTime;
  crinfo[0].grfcadvf = (uint)_OLECADVF.olecadvfModal |
                                (uint)_OLECADVF.olecadvfRedrawOff |
                                (uint)_OLECADVF.olecadvfWarningsOff;
  crinfo[0].uIdleTimeInterval = 1000;
  oleComponentManager.FRegisterComponent(this, crinfo, out pwdId);
}
 

The tool window also should implement the IOleComponent interface with its 11 members.

 public class CSharpStatsToolWindow : ToolWindowPane, 
  IVsWindowFrameNotify3, IOleComponent
 

The most important is the FDoIdle method that runs where the shell is idle:

 int IOleComponent.FDoIdle(uint grfidlef)
{
  ProcessOnIdle();
  return VSConstants.S_OK;
}
 

The work is done by the ProcessOnIdle method that contains “artificial slowing” to support demonstration:

 public void ProcessOnIdle()
{
  if (_IdleCounter++ % Slowing != 0) return;
  string nextFile;
  lock (_FilesToProcess)
  {
    if (_FilesToProcess.Count == 0) return;
    nextFile = _FilesToProcess.Dequeue();
  }
  _FileInfoCollection.Add(_CSharpService.ProcessFile(nextFile));
}
 

Now I show you that this code provides UI responsiveness. For the sake of this demo, I slow idle processing down so that only every sixth FDoIddle call will do effective work.

[Set the Slowing value to 6 and set the UseIdleProcessing flag to true. Open the C# project used to parse before. Show that while the files are parsed, the UI stays responsible, refreshes the list of files parsed. Demonstrate that files can be opened and edited and also the C# statistics tool window can be closed and reopened.]

During this demo you can follow how more and more C# files are parsed during idle processing:

Some remarks: when you close the tool window, idle processing goes on in the background, now it is intentional just because of demo reasons. However, in a real production environment you should implement idle processing so that hiding your tool window suspends the idle processing, showing the tool window enables it again.

Now, let me show how to release and reclaim resources when the tool window is hidden and shown again. I have extended the class providing information about a C# file so that it will allocate one megabyte of memory to put some fake information into it. I will show you how much memory it takes. Here is the code to allocate (and release) memory:

 public class CSharpFileInfo
{
  // --- Members used for demonstration purposes
  const int MaxLength = 60;
  const int BufferSize = 1000000;
  byte[] _WasteMyMemory;
 
  // ------------------------------------------------------------------------
  /// <summary>
  /// Initializes an instance according to the specified file name.
  /// </summary>
  // ------------------------------------------------------------------------
  public CSharpFileInfo(string fileName)
  {
    FullName = fileName;
    FileName = Path.GetFileName(fileName);
    FilePath = Path.GetDirectoryName(fileName);
    AllocateResources();
  }
 
  // --- Public properties for retrieving C# information
  public string FileName { get; private set; }
  public string FilePath { get; private set; }
  public string FullName { get; private set; }
  public int Namespaces { get; set; }
  public int Types { get; set; }
  public int NestedTypes { get; set; }
  public int Members { get; set; }
  public int Methods { get; set; }
  public int Statements { get; set; }
 
  #region Resource allocation methods
 
  // ------------------------------------------------------------------------
  /// <summary>
  /// Allocates fake resources for the class
  /// </summary>
  // ------------------------------------------------------------------------
  public void AllocateResources()
  {
    if (_WasteMyMemory != null) return;
    try
    {
      _WasteMyMemory = new byte[BufferSize];
      var reader = new BinaryReader(File.OpenRead(FileName));
      var bytesRead = reader.ReadBytes(BufferSize);
      bytesRead.CopyTo(_WasteMyMemory, 0);
    }
    catch (SystemException)
    {
      // --- This exception is intentionaly caught
    }
  }
 
  // ------------------------------------------------------------------------
  /// <summary>
  /// Releases fake resources
  /// </summary>
  // ------------------------------------------------------------------------
  public void ReleaseResources()
  {
    _WasteMyMemory = null;
  }
 
  #endregion
}
 

[Set Slowing to 2, the UseResourceSavings flag to false, and run the package. Display the Process Info window. Open the C# project and refresh the C# statistics window. Show that parsing the files in the project consumed something like 450 Mbytes of memory]

Before parsing started:

After parsing finished:

When the user explicitly closes the tool window the memory is not reclaimed. Closing the window is an explicit sign that the user does not intend to deal with the C# Statistics anymore, so why not to release the memory held by this window? I’ve implemented this scenario.

First, I prepared the tool window to catch frame events including hiding and showing the frame. To catch these events we must subscribe to them by passing an IVsWindowFrameNotify3 instance -- in this case this interface is implemented by the tool window itself. The interface implements 5 methods, the one we are interested in is OnShow:

 // ------------------------------------------------------------------------
/// <summary>
/// Responds to the event when the tool window is hidden or shown.
/// </summary>
// ------------------------------------------------------------------------
public int OnShow(int fShow)
{
  if (UseResourceSavings)
  {
    if (fShow == 0)
    {
      // --- Tool window is about to hide
      foreach (var item in _FileInfoCollection)
        item.ReleaseResources();
      GC.Collect();
    }
    else
    {
      // --- Tool window is about to show
      foreach (var item in _FileInfoCollection)
        item.AllocateResources();
    }
  }
  return VSConstants.S_OK;
}
 

As you see the code above, when the window is about to hide, we release all allocated resources. In contrast when the window is to be shown again, we reclaim the resources again.

Now, let’s see the results in practice:

[Set the UseResourceSavings flag to true, the Slowing value to 1. Run the package, and open the Process Info Tool window. Load and analyze the C# project. Show the size of memory consumed after analysis, then close the tool window. Show the memory reservation again.]

This is what you can see before closing the tool window:

When you close the tool window, you can see, resources have been released:

When the tool window is displayed again the resources are reclaimed:

I hope you could see, with a few good techniques you can make your extensions’ UI more responsive and frugal with resources.

Part 3>

DevTools Ecosystem Summit: Best Practices for Extending the IDE with a Focus on Performance, Part 1

2009-10-20T11:32:00Z

I had the opportunity to present at the DevTools Ecocsystem Summit held in Redmond between October 19 and 23. I had two presentations, the first with the title “Best Practices for Extending the IDE with a Focus on Performance”, and the second held in cooperation with Quan To about VS 2010 extension deployment. After the presentations I decided to blog the presentations in a transcript-like way including demos with source code and screenshots.

This post is the first part of my “Performance Focus” presentation.

Good Afternoon! It is great to be here at the DevTools Ecosystem Summit! Welcome to this session, just right after the lunch. I hope you’ve drunk enough coffee… I’m Istvan Novak, a C# MVP and a VSX Insider from Hungary.

I’ve spent a few years with deep diving into VSPackage development, and I would not say it is very easy, mainly because of the lack of documentation and lack of guidance.

It the title of the session I used the expression „Focus on Performance”. Saying this I understand three things that are my main objectives with this session:

First, I’d like to tell you a few interesting technologies and techniques to make you a more efficient Visual Studio Extensibility developer.
Second, I’d like to show you a few tricks that allow your extensions have a great performance and avoid bottleneck issues.
Third, I want to show you a few great potentials in Visual Studio 2010 that makes developing extensions not a challenge but rather fun.

In this session I will use only a few slides and show you a bunch of demos to let you feel what I really mean when saying technologies, techniques and tricks.

As you know and probably have heard quite often, the VS 2010 UI is based on the WPF technology. While VS 2010 still fully supports Windows Forms UI, I suggest you learning WPF and designing your extensions with WPF in mind.

If you have ever used macros or created VS Add-Ins, it is time to get familiar with the Visual Studio 2010 SDK that provides you two more extensibility options:

To possess the full power of extensibility, create Visual Studio Packages with the Managed Package Framework. With packages you can create powerful extension for VS just like if those were shipped with the product.
The Visual Studio SDK also opens you a new way of extending the Visual Studio editor. While in the past doing it was very painful and a hard job, with the new editor extensibility model it becomes fun. During this session, in the other room the VSX 103 session is about creating editor extensions. I suggest you downloading the session video and watching it.

Due to the COM roots of VS creating installation kits and managing deployment had many small annoying details. With VS 2010 VSPackage deployment has been significantly simplified. Visit VSX 102 in the next session slot to pick up more details on this topic.

Well, an important key to become an efficient developer: the ability to avoid the pitfalls our way is often paved with. During the session I will enumerate the most common pitfalls I’ve used to meet and help you avoiding them.

The new .NET Framework 4.0 introduces a new technology called Managed Extensibility Framework. The role of MEF is to help the shift from statically compiled applications into the dynamically composed ones. The full VS 2010 Editor Extensibility model is built on MEF, and you can also leverage on MEF’s great features. If we’ll have enough time at the end of this session I will demo you VSPackage leveraging on MEF.

Those who use the Visual Studio Automation model heavily know how painful it is to using it from C# related to macros or to dynamic languages. C# 4.0 will support extremely useful new language features that ultimately allow using COM object models in C# just like in other scripting or dynamic languages. These include the new dynamic type, optional and named parameters. In this talk I do not dive deeper in to this topics, but I’d encourage you to check what is new is C# 4.0.

If you asked me what I really like in the VS 2010 release I would answer the way how the Visual Studio changes to leverage on more and more managed code. While the majority of VS 2008 user interface is unmanaged, VS 2010 UI is built on the WPF technology which is managed. The new code editor changed its UI to WPF and at the same time also the codebase went to managed code.

The WPF rendering surface is actually a DirectX surface. The performance benefits for complex user interfaces are huge. Large images can be blended and scaled in hardware and the entire scene is double-buffered to allow rich, fluid animations. So these are not HWNDs we’re dealing with – although all WPF applications will have at least one real HWND on the desktop, the contents of that HWND are managed entirely by the WPF compositing and rendering engines.

“Retained mode” is the term used to describe a graphics system where you don’t need to get involved in the painting of your window. Contrast this to HWND-based painting where you have to handle messages such as WM_PAINT and WM_ERASEBACKGND in order to get pixels to light up on the screen. Because each HWND is responsible for painting its own contents, if an application hangs or is slow to respond, this can lead to repaint problems on the desktop – holes in the display. In a retained mode system, such as WPF, you cause the scene to be rendered by adding or updating visual objects in the scene. When the visual object tree changes, then WPF will re-render the window for you.

The kinds of objects in the tree might be simple things such as rectangles or circles. They might be controls such as buttons, checkboxes or toolbars, or they might be advanced visual elements such as a video stream or a 3d model.

Data binding is simply the creation of a reference from one piece of data (a datum) to another. Typically the binding creates a connection between the UI and the application’s business logic. When the source of the binding changes, the target also updates. The “binding” is described using a “binding expression”. A binding expression may be a simple path – for example, “bind the visibility of this button to the value of this boolean property” – or it may describe complex connection between, say the results of a database query and a grid control displaying the results.

Styling allows you to override the default visualization and behavior of any WPF control. Want your buttons to glow and spin when you click them? Styling allows you to specify that behavior once and apply it to all buttons in the visual tree. Templating allows you to specify the visual appearance for all elements in a collection, for example a list box. This is a very powerful mechanism which allows us to apply a visual theme (or a “skin”) across the entire user interface by changing just the root node of our visual tree.

In this demo I am going to show you a simple tool window displaying process information similar to the Task Manager. I have created two separate packages that use perfectly the same logic except the first one is built with Windows Forms UI, the second with WPF. Let’s start them!

The two tool windows look similar; however, the WPF is a bit more sophisticated. When clicking on the column headers we can order the table according to the column clicked, and you also can discover alternating row colorings. Of course, you can do the same effect with Windows Forms by using third-party controls, but the WPF data grid does it for you free out of the box. Try to resize the grid columns both for the top and bottom tool windows. You’ll experience that while the transition in WPF (top) window is smooth, the Windows Forms tool is flickering.

I start Spy++ and show you how windows handle are used by the Windows Forms and WPF solutions.

[Start Spy++. Use the Find Window function with the Hide Spy++ option.]

When I move the target cross over the Windows Forms implementation, you can see that it has two windows within: one for the list view representing the grid and one for the column headers. Now, when I move it over the WPF implementation, you see that the WPF tool window is nested into the main window of VS without any more HWND! By the way, with this technique you can use Spy++ to discover which parts of the new Shell have been moved to WPF and which have not!

Let’s back and see the source codes! As I mentioned earlier the two codes are identical except the user interface definitions. This is the code that populates the Windows Forms with process information. As you can see, it contains operations that make this population in the imperative way:

 // ------------------------------------------------------------------------
/// <summary>
/// Populates the list view control with process data
/// </summary>
// ------------------------------------------------------------------------
public void RefreshData()
{
  ProcessListView.Items.Clear();
  foreach (var processInfo in ProcessList.GetProcesses())
  {
    var item = new ListViewItem(
      new[]
        {
          processInfo.Name,
          processInfo.Id.ToString(),
          processInfo.Priority.ToString(),
          processInfo.ThreadCount.ToString(),
          processInfo.Priority < 8 
            ? "Low (" + processInfo.Priority + ")"
            : "High (" + processInfo.Priority + ")",
          processInfo.WorkingSet.ToString()
      }) { Tag = processInfo };
    ProcessListView.Items.Add(item);
  }
  ProcessListView.SelectedItems.Clear();
  ProcessListView.SelectedIndices.Add(0);
  ProcessListView.Columns[0].AutoResize(ColumnHeaderAutoResizeStyle.ColumnContent);
  ProcessListView.Invalidate();
}
 

In contrast, the WPF solution does it in a declarative fashion due to the data binding feature:

   // ------------------------------------------------------------------------
  /// <summary>
  /// Binds the grid with process data
  /// </summary>
  // ------------------------------------------------------------------------
  public void RefreshData()
  {
    ProcessGrid.ItemsSource = ProcessList.GetProcesses();
  }
}
 

Here the ItemsSource property of the grid is simply assigned to the collection of process information retrieved by the GetProcesses method.

I’m sure, I do not have to tell you which one the simpler is. Let’s have a look at the codes defining the UI. For Windows Forms it is also imperative, the form’s UI is set up by C# code (code extract only):

 private void InitializeComponent()
{
  this.ProcessListView = new System.Windows.Forms.ListView();
  this.NameHeader = ((System.Windows.Forms.ColumnHeader)(new System.Windows.Forms.ColumnHeader()));
  this.IDHeader = ((System.Windows.Forms.ColumnHeader)(new System.Windows.Forms.ColumnHeader()));
  this.ThreadsHeader = ((System.Windows.Forms.ColumnHeader)(new System.Windows.Forms.ColumnHeader()));
  this.HandlesHeader = ((System.Windows.Forms.ColumnHeader)(new System.Windows.Forms.ColumnHeader()));
  this.PriorityHeader = ((System.Windows.Forms.ColumnHeader)(new System.Windows.Forms.ColumnHeader()));
  this.WorkingSetHeader = ((System.Windows.Forms.ColumnHeader)(new System.Windows.Forms.ColumnHeader()));
  this.SuspendLayout();
  // 
  // ProcessListView
  // 
  this.ProcessListView.Columns.AddRange(new System.Windows.Forms.ColumnHeader[] {
        this.NameHeader,
        this.IDHeader,
        this.ThreadsHeader,
        this.HandlesHeader,
        this.PriorityHeader,
        this.WorkingSetHeader});
  this.ProcessListView.Dock = System.Windows.Forms.DockStyle.Fill;
  this.ProcessListView.FullRowSelect = true;
  this.ProcessListView.GridLines = true;
  this.ProcessListView.Location = new System.Drawing.Point(0, 0);
  this.ProcessListView.Margin = new System.Windows.Forms.Padding(4, 4, 4, 4);
  this.ProcessListView.Name = "ProcessListView";
  this.ProcessListView.Size = new System.Drawing.Size(1030, 341);
  this.ProcessListView.TabIndex = 0;
  this.ProcessListView.UseCompatibleStateImageBehavior = false;
  this.ProcessListView.View = System.Windows.Forms.View.Details;
  // 
  // NameHeader
  // 
  this.NameHeader.Text = "Process Name";
  this.NameHeader.Width = 200;
 

WPF uses XAML that is declarative (code extract only):

 <DataGridTextColumn Header="Process Name" Binding="{Binding Name}" 
                    Width="Auto" IsReadOnly="True" />
<DataGridTextColumn Header="Id" Binding="{Binding Id}" 
                    Width="Auto" IsReadOnly="True" 
                    ElementStyle="{StaticResource NumericCellStyle}" />
<DataGridTextColumn Header="Threads" Binding="{Binding ThreadCount}" 
                    Width="Auto" IsReadOnly="True" 
                    ElementStyle="{StaticResource NumericCellStyle}" />
<DataGridTextColumn Header="Handles" Binding="{Binding Handles}" 
                    Width="Auto" IsReadOnly="True" 
                    ElementStyle="{StaticResource NumericCellStyle}" />
<DataGridTextColumn Header="Priority" 
                    Binding="{Binding Priority, Converter={StaticResource PriorityConverter}}" 
                    Width="Auto" IsReadOnly="True" />
<DataGridTextColumn Header="Working Set Size" Binding="{Binding WorkingSet}" 
                    Width="Auto" IsReadOnly="True" 
                    ElementStyle="{StaticResource NumericCellStyle}" 
                    SortDirection="Descending" />
 

You see the Binding attribute of the columns that assign appropriate property of processes with the corresponding column. This XAML file declares the visual attributes of the UI, and it is very powerful. Just adding a few XAML lines without any coding we can use the styling and templating of WPF to solve tasks we use to code with Windows Forms. Here I uncomment the code that defines “mouse over” behavior for grid cells:

 <DataGrid.CellStyle>
  <Style TargetType="DataGridCell">
    <Style.Triggers>
      <Trigger Property="IsMouseOver" Value="True">
        <Setter Property="Background" Value="Yellow" />
        <Setter Property="FontWeight" Value="Bold" />
        <Setter Property="Foreground" Value="Maroon" />
      </Trigger>
    </Style.Triggers>
  </Style>
</DataGrid.CellStyle>
 

And also add a new column to the grid:

 <DataGridTextColumn Header="Window Title" Binding="{Binding WindowTitle}" Width="*" IsReadOnly="True" />
 

When running the modified tool window, we can recognize the effect of changes:

There is a new column in the grid, and as I move the mouse over the cells, the cell colors get changed.

What I showed you is just a tiny part of benefits coming from WPF but I hope it was enough to convince you to turn to WPF when developing your extensions.

Part 2>

Have a look at the new design in Visual Studio 2010

2009-10-19T18:15:11Z

I have just installed Visual Studio 2010 Ultimate Beta2. After starting it you face with the new design:

Also try Extension Manager and New Project…

Visual Studio 2010 Beta2 is available for download

2009-10-19T18:09:01Z

If you have the appropriate MSDN Subscription, you can download Beta2 from now. From official announcement and some mode important dates, please look at Soma’s blog: http://blogs.msdn.com/somasegar/archive/2009/10/19/announcing-visual-studio-2010-and-net-fx-4-beta-2.aspx.

It is also worth to have a look at to the new design of Visual Studio Gallery that illustrates the new “sexy” design of VS 2010: http://visualstudiogallery.msdn.microsoft.com.

Download, install and enjoy!

My sessions on the DevTools Ecosystem Summit

2009-10-18T12:07:06Z

The DevTools Ecosystem Summit will be held between October 19 and 23 in the Microsoft Conference Center, Redmond. The first two days are open for users after free registration, the other days are organized only for VSIP partners and Inner Circle members. I will present two sessions on the conference:

VSX 102: Deploying Visual Studio 2010 Extensions (together with Quan To): Due to the COM roots of Visual Studio and the lack of the right tool set deploying Visual Studio extension requires “creativity” from developers. Visual Studio 2010 is a great leap on this field with its brand new tools and technologies including Extension Manager, Visual Studio Gallery and VSIX. This presentation intends not only to overview of these tools but rather demonstrating how developers can leverage on the synergy of these tools to remove the deployment pain.
VSX 202: Best Practices for Extending the IDE with a Focus on Performance: With Visual Studio 2010, creating extensions has never been easier! In this presentation, I will discuss and demonstrate the benefits of leveraging new Visual Studio technologies such as WPF and MEF, and will show how to optimize performance for your extensions. The talk will cover extensibility best practices with a focus on performance such as keeping your UI responsive, how you can be frugal with resources, and how to lazy-load your extension. Finally, I will show you how to debug those pesky errors that appear during extension development and how to avoid them in the future.

The post conference videos are promised in a few weeks after the conference, I would encourage you to download and watch them. I also plan to present my sessions in a readable form on my blog.

LearnVSXNow! Part #45 – Understanding the Menu Merge Process

2009-10-13T13:53:00Z

Visual Studio extensibility developers know that VSPackages are load on-demand. The IDE loads a package when any of the commands, services, tool windows, document windows, designers, or whatsoever objects the package owns are about to be used. Even if our packages are not loaded, somehow they should indicate their presence: “Hey, here I am installed with Visual Studio… Just click on this button and I’ll be loaded by the shell to stand at your service”.

Generally packages indicate their presence by inserting menu and toolbar items either into one of the main menus, standard toolbars or context menus. Assemblies of packages hold the information the IDE uses to indicate their presence. The dilemma is the following:

If the package holds this information, they should be in the memory to extract the information to be displayed by the IDE. Well, this would totally prevent the frugality of the on-demand loading mechanism.

Visual Studio solves this challenge with the following technique:

Presence information is put into a special binary resource within the assembly representing the package. This is the result of compiling the so-called command table (.vsct file of the package).
When installing the package, Visual Studio takes this resource information out of the assembly and merges the items described there with the standard menus (of course, including toolbars and context menus) of the IDE.

This sounds simple, but in practice, this mechanism is more complex, because several other issues should also be handled:

Removing or uninstalling packages
Handling changes in packages
Packages can be localized for several culture contexts
Startup performance should not be poor

Technically the easiest solution was to merge the menu information of all packages during Visual Studio startup time. The IDE could simply load all the command table resources from package binaries and carry out the merging. Well, from user experience point of view this would not ideal. Just think about that Visual Studio ships with more than hundred packages out of the box. The merge process should scan over one hundred assemblies or native packages for command table resources. Are you sure you wanted this process to be done for every VS startup? I’d rather believe you would pray for a much faster startup.

What Visual Studio does is pre-merging the IDE and package menus. With the devenv /setup command line you could ask Visual Studio to do the whole merging for you.

How Menu Merging Works?

Related to a minor bug I changed a few emails with Paul Harrington, a lead dev from the VS platform team. As a tool for finding the bug, Paul wrote me the merging and startup mechanism in details. I used his description to discover how the little cogs work behind the scenes and here I share it with you.

The menus Visual Studio IDE is about to merge are described in the registry under the HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\<instanceRoot>\Menus key, where <instanceRoot> is the registry root of the Visual Studio instance you work with. For example, for VS 2008 it is 9.0, for VS 2010 it is 10.0_Config, for VS 2010 Experimental Instance this key is 10.0Exp_Config. The next figure illustrates the content of this registry key:

The key has entries with type of REG_SZ for each package having menu resources to be merged with the IDE. Each entry contains a name (like Menus.ctmenu) and a version number separated by a comma. When merging the menus, Visual Studio extracts the resources here, creates the merge and saves the result into a file named devenv.CTM where the extension name stands for “Commands, Toolbars and Menus”. This file serves as a “merged menu cache”. When Visual Studio starts, it checks if there is valid “merged menu cache file” or not. While a valid file is found, the IDE reads the file and uses its cached content to build up the menus. When the file is found invalid, Visual Studio creates the file again by merging the appropriate package resources again.

Checking the devenv.CTM file’s validity

During the merge process Visual Studio calculates a checksum from the content of the values under the Menus registry key. This checksum value is saved into the devenv.CTM file. At startup time the IDE looks for the devenv.CTM file in a few folders using the locale IDE of the installed VS language. For the English version this is 1033, for other languages substitute it with the appropriate ID. Folders are searched in the following order:

Local AppData folder. Assuming your operating system is installed on drive C:, it is C:\ProgramData\Microsoft\VisualStudio\<instanceRoot>\1033.
Per-user local (non-roaming) AppData folder. It should be something like C:\Users\<userName>\AppData\Local\Microsoft\VisualStudio\<instanceRoot>\1033.
The folder containing devenv.exe. This is the Common7\IDE folder under your Visual Studio installation root.

The CTM file is hidden, so you must also display the hidden files if you want to see it in Windows Explorer. Because the local AppData folder and the Visual Studio installation folder require elevated permissions to write into them, there is a high likelihood that you will find this file in your per-user local AppData folder, just like in my case:

If the IDE does not find the devenv.CTM file, or find it, but the checksum stored in that file does not equal with the value calculated from the Menus key’s content, the IDE takes the merged menu file into account as invalid (or obsolete) and starts building up the new merged menu file.

The merging process

The IDE iterates through the packages registered with the Menus key and looks for the localized resources (according to Visual Studio’s installation language). Reads the resources and merges the command+toolbar+menu contributions into a master list. When all packages are merged into this list, it is written to the CTM file together with the calculated checksum. The IDE tries to write to the locations (1-3)used to search this file. Because the local AppData folder and Visual Studio installation root require elevated permissions, generally the file is written into the per-user local AppData folder.

Relation to devenv /setup

The merging process happening with devenv /setup is the same as above, but there are a few differences:

devenv /setup always carries out merging even when the checksums match.
devenv /setup must be run with elevated permissions, so it should always be able to write to the local AppData folder.
devenv /setup creates the merged menu file for all installed languages.

I hope, these details will help you understand how your extensions’ commands, menus and toolbars are merged into the UI of Visual Studio and also give you starting point for troubleshooting.

Visual Studio 2010 and .NET 4.0 Book with Dotneteers

2009-09-26T08:15:00Z

It is a great thing to announce that Dotneteers are now involved in the authoring team of a new book with working title “Visual Studio 2010 and .NET 4.0 Six-in-One”. The book is to be published by Wrox in Q1 next year in a team work of ten, including well-known authors, Hungarian MVPs and community members. Here is the list of authors in alphabetical order:

Balássy, György

Gránicz, Ádám

Hajdrik, Attila

Hillar, Gaston

Kanjilal, Joydip

Molnár, Ágnes (OBA, Sharepoint and Aghy)

Novák, István (DiveDeeper VSX)

Sellers, Mitch

Smulovics, Péter (My.Mountains[])

Velvárt, András (VBandi’s musings on WPF, Silverlight and UX)

When we have any news and more information about the book, I will share those with you.

VS 2010 Beta1 Issues #3: Cancel Button in Extension Manager

2009-07-05T12:31:00Z

The new Extension Manager is a great piece of Visual Studio 2010, I like the UI (even if it has fuzzy font by default J), but I have found that it has a button name Cancel. I’d rather name this button Close, because it does not behave like Cancel in other places.

For me, the name “cancel” suggest that by clicking it I can roll back any changes I have made on this dialog. When the Extension Manager appears on the screen, Cancel tells me this.

When I click on Cancel, no changes are saved, and the dialog simply closes. However, when I make some changes, for example remove one of the installed extensions, I face with the following dialog:

Here the Cancel button is a bit misleading, you may think you can undo the uninstall operation by clicking on it. It might be suspicious that clicking the Cancel button does not ask you a confirmation, but simply closes the dialog. Actually the message with the light yellow background tells you that “some extensions have been changed”, but it does not explicitly tell that those cannot be simply rolled back.

The same happens if you use the Disable/Enable buttons for an installed extension. Renaming the Cancel button to Close would make the situation clear, because it would not implicitly suggest you that you can undo the changes you’ve done using the Extension Manager.