Visual Studio Integration SDK Roadmap
Creating a VSPackage is a powerful way to extend Visual Studio. In fact, Visual Studio includes many components that are VSPackages, for example, the editor, the debugger, and predefined toolbars. Therefore, developing and deploying a VSPackage is like producing the core functionality of Visual Studio 2008 itself.
VSPackages
You can create VSPackages by using Visual C#, Visual Basic, or Visual C++. You can use VSPackages to extend the Visual Studio integrated development environment (IDE) by creating project types, menu commands, tool windows, document editors, and much more. The Visual Studio Integration SDK contains tools, samples, wizards, designers, and documentation that are designed to help you create VSPackages.
The following diagram shows a high-level view of the Visual Studio architecture.
At the base of the diagram is the IDE itself, which is what you are extending. The IDE can be controlled in two ways, by using automation or by using the Package API.
Typically, automation is programmed by using add-ins or macros. For more information, see Automation and Extensibility for Visual Studio.
VSPackage programmers use the Package API, which is the same API that Microsoft uses to develop Visual Studio. If you use C++, you can call the Package API by using a template-based library named the Visual Studio Library (VSL).
The Package API can also be called from managed code, either by calling the .NET Visual Studio Interop assemblies, or by using the Managed Package Framework (MPF).
For more information, see
Managed Package Framework
The MPF is a set of helper classes that call the .NET Visual Studio Interop assemblies. Most of the classes and interfaces in the MPF can be found in the Microsoft.VisualStudio.Package and Microsoft.VisualStudio.Shell namespaces.
The MPF provides the base class, Package. The Package class provides a managed implementation of several useful interfaces. Without writing much code, you can create a VSPackage by deriving your VSPackage class from the Package class and attaching various attributes to it.
After you build a VSPackage assembly, you use the regpkg.exe utility to register it. The regpkg.exe utility examines the VSPackage assembly and registers the VSPackage in the system registry by using the information it finds in the attributes.
For more information, see
The Experimental Hive
To test a VSPackage extension, you run Visual Studio under a separate system registry hive named the experimental hive and register the VSPackage there. Doing this lets you test your extension without worrying about whether your "real" installation of Visual Studio will be damaged.
The experimental hive is created when you install the Visual Studio SDK. During installation, the Visual Studio registration entries are copied into the experimental hive. You can reset the experimental hive at any time by running Reset the Microsoft Visual Studio Experimental Hive in the Microsoft Visual Studio SDK/Tools folder on the Start menu. For more information, see Experimental Build.
Services
A service is a contract between two VSPackages. One VSPackage provides a specific set of interfaces for another VSPackage to consume. Use a service when two VSPackages must exchange information or when one VSPackage must access the functionality of another. Many of the VSPackages that are included in Visual Studio are interconnected by services.
Some services are included in Visual Studio. For example, included services enable tool windows to be shown or hidden dynamically, enable access to Help, status bar, or UI events, and enable access to a code editor. You can take advantage of the included services when you deploy your own VSPackages.
For more information, see
Commands
When you create user interface (UI) elements such as buttons, the buttons are actually a visual representation of a command. You may have seen this design before. For example, when you customize a toolbar in a product such as Microsoft Word, you add buttons to a toolbar by dragging a command to the toolbar. In Visual Studio, a user accesses most functionality by using commands.
For example, when you click Build Solution on the Build menu, you are using a menu "button" to execute the Build Solution command. You can see this connection when you right-click the menu bar in Visual Studio, and then click Customize. When the Customize dialog box opens, click the Build menu to reveal the names of the commands that are currently on the menu. However, clicking the command names does not run the commands. Right-click the Build Solution command name to reveal the customization form, as shown in the following picture.
By using the customization form, you can change the command name, but you cannot change what the command does. The command name "button" is just a visual representation of the command, as opposed to a button that has a command attached to it. If you want a different command, you must drag one from the Customize dialog box to the menu. Doing this adds a command name "button" that represents the new command.
Commands can be issued in various ways in the IDE. For example, if you right-click the name of a solution in Solution Explorer, the Build Solution command is available on the shortcut menu. If you show the Build toolbar, the command is available as a graphical button. Visual Studio even provides a tool window in which you can issue commands at a command prompt. To show this window, on the View menu, point to Other Windows and then click Command Window.
In the Command Window, commands are grouped by category and can be entered interactively by typing the category, a period, and then the command. For example, to run the Build Solution command, you type Build.BuildSolution and then press ENTER.
Notice that when you type the period after "Build," an IntelliSense window opens and shows you the commands that are available in the Build category. The categories that you can use in the Command Window are the same as the ones in the Customize dialog box, except that they may not contain spaces. For example, the Class Diagram commands are available by typing ClassDiagram.
When you extend Visual Studio, you can create commands and add them to the IDE. You can specify how these commands will appear in the IDE, for example, on a menu or toolbar. Typically, a custom command would appear on the Tools menu, and a command for displaying a tool window would appear on the Other Windows submenu of the View menu.
For more information, see How VSPackages Add User Interface Elements to the IDE.
Menus and Toolbars
Menus and toolbars provide a graphical way for VSPackage users to access its commands. Commands are functions in VSPackages that accomplish tasks, such as printing a document, refreshing a view, or creating a new file.
Menus are rows or columns of commands that typically are displayed as individual text items at the top of the IDE or a tool window. Submenus are secondary menus that appear when a user clicks commands that include a small arrow. Shortcut 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 Menu Tasks.
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.
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 respond in a hierarchical manner, 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
Tool Windows and Document Windows
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.
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
Video: Iterate through the Items in the Error List
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
You use an editor to create and modify the code and other text in your applications.
The Visual Studio editor is a VSPackage. The Visual Studio SDK editor model lets you include the Visual Studio editor in your own VSPackages, and it also lets you create your own custom editors or call external editors. Not only is Visual Studio editor functionality used in the code entry window, it is also used in other text-entry features such as the Output window and the Command Window.
Editors can also be form-based, as shown by the Visual Basic forms designer.
The kinds of editors that you can use in Visual Studio 2008 are as follows:
The Standard File-based Editor, which provides basic editor functionality.
The Visual Studio 2008 Core Editor, which contains the functionality of the Standard editor, plus features such as the ability to take advantage of specific Visual Studio 2008 project types.
A custom editor that you have designed for a custom project type.
An external editor such as Notepad or Microsoft WordPad.
For more information, see
Projects
In Visual Studio 2008, projects are the containers that developers use to organize the source code files and other resources that appear in Solution Explorer. Typically, projects are files that store references to source code files and resources such as bitmap files. 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 2008 project system by providing project types, project subtypes, or 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
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.
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
Language Services
If you want the Visual Studio editor to support new programming keywords or even a new programming language, create a language service or modify an existing one. Each language service may implement certain editor features fully, partially, or not at all. Language service classes provide full support for frequently used features and partial support for some other features. You can use managed language services (with Visual C#) or unmanaged language services (with Visual C+).
At the heart of a language service are a parser and a scanner. A parser converts a programming language source file into discrete elements that are known as tokens. When you create a language service, you write configuration files for both the parser and the scanner so that Visual Studio can understand the tokens and grammar of the new language service. Depending on how it is configured, the language service can provide syntax highlighting, brace matching, IntelliSense support, and other features in the editor.
Note
Although Visual Studio 2008 does not include a parser and a scanner, it is designed to work with Flex and Bison.
For more information, see
Implementing a Language Service By Using the Managed Package Framework.
Walkthrough: Creating a Language Service (Managed Package Framework)
Visual Studio Shell-Based Applications
If you create a custom tool that would benefit from having its own version of the Visual Studio IDE, you can build on the Visual Studio Shell. The Visual Studio Shell provides a hierarchal project system, integration with editors and designers, source code control, and many other features that can support and enhance your custom tool. In addition to acquiring the look of Visual Studio, your custom tools built on the Visual Studio Shell have access to the features of the Visual Studio IDE.
The Visual Studio 2008 Shell has two modes, integrated mode and isolated mode. Each mode addresses a different market, as follows:
The Visual Studio 2008 Shell (integrated mode) integrates into Visual Studio on an end-user computer and enables your custom tools to have the look of Visual Studio. By using the integrated Shell, you can provide custom tools that your customers can use together with Visual Studio. Integrated mode is optimized to host language and software tool products.
The Visual Studio 2008 Shell (isolated mode) lets you create unique and self-contained custom tools that run side-by-side with other versions of Visual Studio that are installed on a computer. 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
MSDN Webcast: Build Tools for Any Platform with the VS 2008 Shell
Video: Create a VSPackage for a Visual Studio Isolated Shell (Part 2)
Video: Create a Setup Project for Visual Studio Isolated Shell (Part 3)
What's Next
The Visual Studio SDK includes tutorials that teach how to create VSPackages, give them functionality, integrate them into Visual Studio, and distribute them to other users. For more information, see Tutorials for Customizing Visual Studio By Using VSPackages