Introduction to the Visual Studio 2008 Shell

In the next Visual Studio wave of products, Microsoft will distribute its world-class IDE freely via its VS 2008 Shell offerings. In this article, I will give an overview of what the Shell is, what it contains, and how you can start leveraging it to start creating your own tools IDE.

The Visual Studio 2008 Shell is a new edition of Visual Studio offered to developers who wish to build their own development tools inside the Visual Studio IDE. Its target users are not the typical developers who would use the other editions of Visual Studio. The Shell’s target users are ISVs and other developers who wish to build their own tools IDEs, and in turn ship to their users and customers.

The key benefit of the Shell is that it allows anyone to quickly build their own tools environment, leveraging a proven and solid foundation of the Visual Studio IDE. By building on the Visual Studio Shell, you can significantly accelerate your development time by focusing on your core tools instead of building and maintaining the environment. In addition to the core IDE features such as menus/commands and tool window framework, the Shell also includes a rich set of component features that you may be able to take advantage of, including the Windows Forms designer and the WPF Designer. Your end-users will also benefit from the familiar user interface of Visual Studio in your tools environment.

A Word About Isolated versus Integrated Mode

Visual Studio 2008 Shell is actually offered as two “modes”: VS 2008 Shell (isolated mode) and VS 2008 Shell (integrated mode). These are, in fact, two separate binary downloads. While the Shell (isolated mode) is a brand-new offering, the Shell (integrated mode) is the new name for the Premier Partner Edition, which was offered in Visual Studio .NET 2003 and Visual Studio 2005. Both offerings share identical feature components.

You may have heard members of the VSX team use the term AppId (short for application identity) to talk about different instances of environments. Each AppId is uniquely identified by a stub .exe (the executable you run to start the environment) and a registry root that stores application configuration. For example, Standard and Professional editions are the same AppId. If you install Standard and Professional on to the same machine, you end up with a Visual Studio environment that contains features from both editions and you cannot start one without the other. On the other hand, Visual Basic Express and Visual C# Express are two different AppIds. If you have both installed, you can still launch them independently and their settings are isolated from each other.

If you use the Visual Studio Shell in the integrated mode, you are building on top of the same Visual Studio instance as the other Visual Studio editions (Standard, Pro, Team Architect, etc.). This means that your tools will merge into the same environment as the other editions of Visual Studio if they are also installed on the user’s machine (top of Figure 1).

If you use the Visual Studio Shell in the isolated mode, you will actually create your own AppId. Your tools environment will be isolated with other Visual Studio AppIds as well as other environments that are built on the Visual Studio Shell (bottom of Figure 1). You will have your own stub .exe, your own custom branding, and registry isolation.

When should you use which? Each mode offers its own benefits and that will depend on your scenarios. Typically, if you are integrating your own language tools, you will benefit from the integrated mode because if your user also has other editions of Visual Studio (Standard and above) installed, they will benefit from mixed language development as well as the extra features offered by Visual Studio such as unit testing, code profiling, and static analysis. On the other hand, if you require your own custom branding in your tools IDE and you want to have it run in complete isolation with Visual Studio, the isolated mode would be the right fit for you.

The walkthrough section of this article focuses exclusively on the isolated Shell. The reason is that developing VSPackages for the integrated Shell is no different than the general VSPackage development for Visual Studio. You can find abundant resources on MSDN and elsewhere about general VSPackage development. Unless explicitly stated, I will simply use “Shell” to refer to it from this point onwards. I will go over the features and customization points contained in the Shell. I will also walk through how you can leverage this new product offering to help you build your own development tools environment.

By: James Lau

VSX Team Member

James Lau

Lead Program Manager

Visual Studio Ecosystem Team

There are so many things going on in our team and in the VSX Community! From holding developer labs to engaging with MVPs, and from shipping the Visual Studio Shell to rethinking the tooling experience in the Visual Studio SDK, we are dedicated to enabling ISVs and enthusiasts in extending Visual Studio. For me personally, it’s really exciting to see the VSX Community harness its creativity and create innovative projects that make Visual Studio an even better product. I am thrilled about all the upcoming Visual Studio SDK enhancements that we have planned over the next year to make extending Visual Studio easier! You can find my blog at http://blogs.msdn.com/jameslau/.