Inside the Visual Studio SDK

There are many ways to extend Visual Studio. Three common ones are: automation, VSPackage extensions, and Managed Extensibility Framework (MEF) extensions.

Automation is primarily used to automate repetitive tasks, as with macros and add-ins, or provide a structure for user input, as with wizards.

Creating a VSPackage is a powerful way to extend Visual Studio. Visual Studio includes many components that are VSPackages, for example the debugger and predefined toolbars. A VSPackage extension can access and extend many of the components of Visual Studio, such as the shell and the project system.

The Managed Extensibility Framework (MEF) is an extensibility mechanism that is used for the first time in the Visual Studio 2010 editor. MEF allows you to customize and extend the editor without having to create a VSPackage.

The Visual Studio Extensibility Model

The Visual Studio extensibility model is composed of the different libraries that allow extenders to access and extend Visual Studio components.

The first layer of the model is found in the Visual Studio API, which is the same set of interfaces that Microsoft developers use to develop Visual Studio. You can use a template-based library named the Visual Studio Library (VSL) to write extensions in unmanaged code.

If you are writing an extension in managed code, you can use the Visual Studio interop assemblies directly, or you can use the Managed Package Framework (MPF). The Managed Package Framework provides classes that wrap many of the interfaces in the Visual Studio API.

If you are extending the Visual Studio 2010 editor, you can use the editor assemblies as well as the MEF assemblies that define the contracts by which your extension is advertised to the Visual Studio editor.

For more information, see:

Visual Studio Services

A service provides a specific set of interfaces for components to consume. Visual Studio provides a set of services that can be used by any components, including extensions. For example, Visual Studio services enable tool windows to be shown or hidden dynamically, enable access to Help, status bar, or UI events. The Visual Studio 2010 editor also provides services that can be imported by editor extensions.

For more information, see:

Visual Studio Extensible Components

The following components are the ones most often used by Visual Studio extensions:

  • Shell Commands

  • Menus and Toolbars

  • Tool Windows

  • Document Windows

  • Editors

  • Language Services

  • Projects

  • Templates

Commands

Commands are functions that accomplish tasks, such as printing a document, refreshing a view, or creating a new file.

When you extend Visual Studio, you can create commands and register them with the Visual Studio shell. You can specify how these commands will appear in the IDE, for example, on a menu or toolbar. Typically a custom command appears on the Tools menu, and a command for displaying a tool window would appear on the Other Windows submenu of the View menu.

When you create a command, you must also create an event handler for it. The event handler determines when the command is visible or enabled, lets you modify its text, and guarantees that the command responds appropriately when it is activated. In most instances, the IDE handles commands by using the IOleCommandTarget interface. Commands in Visual Studio are handled starting with the innermost command context, based on the local selection, and proceeding to the outermost context, based on the global selection. Commands added to the main menu are immediately available for scripting.

For more information, see How VSPackages Add User Interface Elements to the IDE.

Menus and toolbars provide a way for users to invoke commands. Menus are rows or columns of commands that typically are displayed as individual text items at the top a tool window. Submenus are secondary menus that appear when a user clicks commands that include a small arrow. Context menus appear when a user right-clicks certain UI elements. Some common menu names are File, Edit, View, and Window. For more information, see Common Tasks with Commands, Menus, and Toolbars.

Toolbars are rows or columns of buttons and other controls, such as combo boxes, list boxes, and text boxes. Toolbar buttons typically have icon images, such as a folder icon for an Open File command or a printer for a Print command. All toolbar elements are associated with commands. When you click a toolbar button, its associated command runs. In the case of a drop-down control, each item in the drop-down list is associated with a different command. Some toolbar controls, such as a splitter control, are hybrids. One side of the control is a toolbar button and the other side is a down arrow that displays several commands when it is clicked.

For more information, see

Tool Windows

Tool windows are used in the IDE to display information. Toolbox, Solution Explorer, Properties window, and Web Browser are examples of tool windows.

Tool windows typically offer various controls with which the user can interact. For instance, the Properties window lets the user set properties of objects that serve a particular purpose. The Properties window is specialized in this sense, but also general because it can be used in many different situations. Similarly, the Output window is specialized because it provides text-based output, but general because many subsystems in Visual Studio can use it to provide output to the Visual Studio user.

Consider the following picture of Visual Studio, which contains several tool windows.

Screen shot

Some of the tool windows are docked together on a single pane that displays the Solution Explorer tool window and hides the other tool windows but makes them available by clicking tabs. The picture shows two other tool windows, the Error List and Output window, docked together on a single pane.

Also shown is the main document pane, which shows several editor windows. Although tool windows typically have just one instance (for example, you can open only one Solution Explorer), editor windows can have multiple instances, each of which is used to edit a separate document but all of which are docked in the same pane. The picture shows a document pane that has two editor windows, one form designer window, and a browser window that shows the Start Page. All the windows in the document pane are available by clicking tabs, but the editor window that contains EditorPane.cs file is visible and active.

When you extend Visual Studio, you can create tool windows that let Visual Studio users interact with your extension. You can also create your own editors that let Visual Studio users edit documents. Because your tool windows and editors will be integrated into Visual Studio, you do not have to program them to dock or appear on a tab correctly. When they are correctly registered in Visual Studio, they will automatically have the typical features of tool windows and document windows in Visual Studio.

For more information, see

Document Windows

A document window is a framed child window of a multiple-document interface (MDI) window. Document windows typically are used to host text editors, form editors (also known as designers), or editing controls, but they can also host other functional types. The New File dialog box includes examples of document windows that Visual Studio provides.

Most editors are specific to a programming language or to a file type, such as HTML pages, framesets, C++ files, or header files. By selecting a template in the New File dialog box, a user dynamically creates a document window for the editor for the file type that is associated with the template. A document window is also created when a user opens an existing file.

Document windows are restricted to the MDI client area. Each document window has a tab on the top, and tab order is linked to other windows that may be open in the MDI area. Right-clicking the tab of a document window displays a shortcut menu that includes options to split the MDI area into multiple horizontal or vertical tab groups. Splitting the MDI area enables multiple files to be viewed at the same time.

For more information, see

Editors

The Visual Studio 2010 Editor is a new kind of Visual Studio component. While the new editor is itself a VSPackage, it allows you to customize it and use it for your own type of content by means of the Managed Extensibility Framework (MEF). In many cases you will not need to create a VSPackage to extend the editor, although if you want to include features from the shell (for example, a menu command or a shortcut key), you can combine a MEF extension with a VSPackage.

You can also create a custom editor, for example if you wish to read and write to a database, or if you wish to use a designer. You can also use an external editor such as Notepad or Microsoft WordPad.

For more information, see Editors.

Language Services

If you want the Visual Studio editor to support new programming keywords or even a new programming language, you create a language service. Each language service may implement certain editor features fully, partially, or not at all. Depending on how it is configured, the language service can provide syntax highlighting, brace matching, IntelliSense support, and other features in the editor.

At the heart of a language service are a parser and a scanner. A scanner (or lexer) divides a source file into elements that are known as tokens, and a parser establishes the relationships among those tokens. When you create a language service, you must implement the parser and the scanner so that Visual Studio can understand the tokens and grammar of the language.

You can create managed or unmanaged language services.

For more information, see

Projects

In Visual Studio, projects are the containers that developers use to organize and build the source code and other resources. Projects let you organize, build, debug, and deploy source code, references to Web services and databases, and other resources. VSPackages can extend the Visual Studio project system by providing project types, project subtypes, and custom tools.

Projects may also be gathered into a solution, which is a grouping of one or more projects that work together to create an application. Project and status information that pertains to the solution is stored in two solution files, the text-based solution (.sln) file and the binary solution user option (.suo) file. These files are similar to the group (.vbg) files that were used in earlier versions of Visual Basic, and the workspace (.dsw) and user options (.opt) files that were used in earlier versions of Visual C++.

For more information, see

Project and Item Templates

Visual Studio includes predefined project templates and project item templates. You can also make your own templates or acquire templates from the community, and then integrate them into Visual Studio. The MSDN Code Gallery is the place to go for templates and extensions.

Templates contain the project structure and basic files that are required to build a particular kind of application, control, library, or class. When you want to develop software that resembles one of the templates, create a project that is based on the template and then modify the files in that project.

Note

This template architecture is not supported for Visual C++ projects. For information about how to create Visual C++ project templates, see Designing a Wizard.

For more information, see Adding Project and Project Item Templates.

Integrated Shell and Isolated Shell Applications

You can integrate your extension into Visual Studio in either integrated mode or isolated mode.

  • Using the integrated shell allows you to provide custom tools that your customers can use together with other Visual Studio components. The integrated shell is optimized to host language and software tools.

  • Using the isolated shell allows you to create custom tools that run in the Visual Studio shell with only those Visual Studio components that you choose to include. The isolated shell is optimized for specialized tools that have full access to Visual Studio services but also have a custom appearance and branding.

For more information, see