This documentation is archived and is not being maintained.

Visual Studio Integration Guided Tour

[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]

Visual Studio is a powerful, feature-rich tool for software development that is widely used throughout the software industry. Nevertheless, it may not be able to do everything that you need it to do straight out of the box. Therefore, Microsoft provides several ways for you to customize and extend Visual Studio, whether you are producing commercial software, supervising the efforts of an engineering team, or just trying to make your own daily tasks easier. All the ways to customize and extend Visual Studio come under the general category of Visual Studio integration.

By using Visual Studio integration features, you can modify or extend most of the integrated development environment (IDE). Visual Studio provides various levels of access to its functionality, such as:

  • Automating repetitive tasks by using scripts.

  • Adding new tool windows to the IDE.

  • Creating powerful custom editors.

  • Integrating custom languages and keywords.

  • Extending the debugger.

  • Customizing the behavior of Domain-Specific Language (DSL) functionality in Visual Studio. (A domain-specific language, unlike a general-purpose language, is designed to be used for a specific task in a fixed problem domain.)

  • Tapping directly into Visual Studio by developing VSPackages.

This topic provides an overview of all areas of Visual Studio integration. It also provides links to videos that show you how to accomplish integration tasks, and links to conceptual material, how-tos, walkthroughs, and other extensibility documentation. Use this topic as a springboard to learn about the many available extensibility technologies.


Writing a macro is the quickest way to gain access to the Visual Studio object model. Use macros when you want to automate Visual Studio behavior and when you are unconcerned that others can view your macro code.

Macros are sometimes referred to as the binding glue of Visual Studio. You can combine Visual Studio commands or set automation properties to create a useful behavior, such as turning off line numbers in your editor or turning off word wrap.

To start writing a macro, point to Macros on the Tools menu, and then click Macros IDE. Visual Studio includes sample macros from which you may borrow code to use in your own macros.

For more information, see:


By developing add-ins, you can take advantage of the Visual Studio object model in ways that are not possible by writing macros. For example, you can integrate new user interface (UI) elements, such as tool windows or options pages, into the IDE, dynamically enable commands, or add branding to the splash screen or Help About dialog box. Features offered by add-ins can fit into the IDE as if they are part of Visual Studio. You may create add-ins by using Visual C#, Visual Basic, or Visual C++.

Unlike macros, add-ins are compiled into binary code. Because they are compiled, your intellectual property cannot be easily viewed. On the other hand, add-ins are easier to deploy than VSPackages, although you can do more with VSPackages. VSPackages are discussed later in this topic.

For more information, see:


Compared to writing macros and developing add-ins, developing VSPackages is the most powerful way to extend Visual Studio. All components that are included in Visual Studio, such as the editor, the debugger, and predefined toolbars, are VSPackages. Therefore, developing and deploying a VSPackage is like producing the core functionality of Visual Studio itself.

Only VSPackages let you access the internal COM-based extensibility layer of Visual Studio. The extensibility layer contains interop assemblies that enable a VSPackage to access extensibility interfaces from managed code. To successfully develop a VSPackage, you must learn the interop assemblies. After you do this, you may program VSPackages in Visual C#, Visual Basic, or Visual C++. Visual Studio also provides a wizard to help you create a VSPackage.

For more information, see:


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. Visual Studio itself is a collection of VSPackages that are interconnected by services.

Some services are included with Visual Studio. For example, those that 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 are included. You can take advantage of the included services when you deploy your own VSPackages.

For more information, see:

Managed Language Services

If you want to extend Visual Studio to work with new programming keywords or even with a new programming language, use Managed Language Services to create or modify a language service. (Managed Language Services works with Visual C#. You can accomplish the same results by using unmanaged language services with Visual C++.)

A language service provides support in the editor for a programming language. Each language service may implement certain Visual Studio features fully, partially, or not at all. Language service classes provide full support for frequently used features and partial support for some other features.

At the heart of a language service are a parser and a scanner. Although Visual Studio does not include a parser and a scanner, it is designed to work with Flex and Bison, which are open-source tools that are freely available on the Internet.

A parser converts a programming language source file into discrete elements known as tokens. The associated language service can then provide syntax highlighting, brace matching, IntelliSense support, and other features by interpreting the tokens. You must write configuration files for both the parser and the scanner so that Visual Studio can understand the tokens and grammar of your new language service.

For more information, see:

Tool Windows

Watch a 3-minute video overview about tool windows: coming soon!

Tool windows are used in the IDE to display information. Toolbox, Solution Explorer, Properties window, and Web Browser are examples of tool windows. When you have written a custom tool, you may want to program a tool window so that users can interact with the tool.

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, forms 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 languages or to a type of file, such as HTML pages, framesets, C++ files, or header files. Users dynamically create document windows By selecting a template in the New File dialog box, a user dynamically creates a document window for the editor 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:


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. In addition to being used in the code entry window, vsprvs editor functionality is 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.

Here are the kinds of editors that you can use with Visual Studio:

  • The Standard File-based Editor, which provides basic editor functionality.

  • The Visual Studio Core Editor, which contains all the functionality of the Standard editor plus features such as the ability to take advantage of specific Visual Studio project types.

  • A custom editor that you have designed for a custom project type that you have created

  • An external editor such as Notepad or Microsoft WordPad.

For more information, see:

Menus and Toolbars

Menus and toolbars provide a graphical way for users of your VSPackage 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:


In Visual Studio, projects are the containers that developers use to organize source code files and other resources that appear in Solution Explorer. Typically, projects are files that store references to source code files and resources like bitmap files. For example, the extension for a Visual C# project file is .csproj. 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 in three main ways: 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 different 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:



A number of predefined project templates and project item templates are included with Visual Studio. You can also make your own project templates or acquire templates from the community. You can use any one of the project templates to create a basic project container and a preliminary set of items for your application, class, control, or library.


The template architecture described in this section is not supported for Visual C++ projects. For information about creating Visual C++ project templates, see Designing a Wizard.

For more information, see:

Source Control

Visual Studio supports two kinds of source control integration: a source control plug-in that provides basic functionality and is built by using the Source Control Plug-in API (formerly known as the MSSCCI API), and a VSPackage-based source control integration solution that provides more robust functionality. A Source Control Plug-in is written as a DLL that implements the Source Control Plug-in API. Registration and source control integration functionality is provided through the API. This approach is easier to implement than VSPackage-based source control and uses the Visual Studio UI for most source control operations. A VSPackage-based implementation lets you develop a customized replacement for the Visual Studio source control UI. This approach gives you complete control over source control integration, but it does not let you take advantage of the Plug-in functionality. Instead, it requires that you provide the UI and implement the interfaces on your own.

For more information, see:

Help Integration

Context sensitivity is a Help feature that lets Help authors and VSPackage developers create relationships between objects in the IDE and Help topics. At run time, whenever a context-sensitive object is selected, a user can access the related Help topic by pressing F1 or by clicking a button on the object. If the user presses F1 or clicks the button, the local Help browser (Microsoft Document Explorer, for example) is opened if it is not already open, and the topic is displayed.

Context-sensitive Help can be provided for editors, designers, tool windows, project hierarchies, hierarchy items, dialog boxes, language services, or designers.

Help authors and VSPackage developers work together to create context-sensitive Help. The Help author creates a compiled Help collection that contains Help topics and associated keywords and attributes. By using the keywords, the VSPackage developer connects relevant IDE objects to the Help collection so that the correct topic is displayed whenever a user requests Help on a selected object. For more information, see:

Domain-Specific Language (DSL) Tools

A domain-specific language, unlike a general-purpose language, is designed to be useful for a specific task in a fixed problem domain. By using Domain-Specific Language Tools, you can define a new modeling language and implement it easily. For example, you can create a specialized language to describe a user interface, a business process, a database, or the flow of information, and then generate code from those descriptions.

You can use Domain-Specific Language Tools to generate visual designers that are customized for your problem domain. For example, you can create a tool to describe concepts that are specific to the way your organization models business processes. If you are building a state chart tool, you can describe what a state is, what properties a state has, what kinds of states exist, how transitions between states are defined, and so on. A state chart that describes the status of contracts in an insurance company is superficially similar to a state chart that describes user interaction among pages on a Web site, but the underlying concepts differ significantly. By creating your own domain-specific language and custom generated designer, you can specify exactly which state chart concepts you require in your tool.

For more information, see:

Team Edition for Testers

Visual Studio Team Edition for Testers includes a suite of test tools that are closely integrated with Visual Studio 2005. The tools work not only in their own testing framework, but also in a larger framework of software life cycle tools.

Visual Studio Team Edition for Testers lets you create, manage, edit, and run tests, and also obtain and store test results. Several test types, which include unit tests, Web tests, load tests, and manual tests, are integrated into Visual Studio. Measurement of code coverage is also integrated. You can extend Visual Studio Team Edition for Testers by adding your own test types.

For more information, see:

Data Designer (DDEX)

Data Designer Extensibility (DDEX) lets you extend data designers in Visual Studio to communicate with most external data source at design time, expose its object hierarchy, and show hierarchy views in Server Explorer. In addition, DDEX enables participation by external data sources in drag-and-drop functionality, object property visibility, and features of the Visual Studio designers.

The Data Designer Extensibility SDK provides documentation, samples, and resources to help you implement a DDEX provider.

For more information, see:

Debugging SDK

The Visual Studio Debugging SDK provides the information that you must know before you can customize Visual Studio debugger components or create your own debugger components for use in the IDE.

You can use Visual Studio debugging to step through a multilanguage application, and you can edit variables while you are debugging an application.

Visual Studio debugging is executed out-of-process with the program being debugged. Because debugging is less intrusive in the process space of the application, it is easier to write components that interact with the debugger but do not affect your debugging program.

To best use the Visual Studio Debugging SDK, you should be familiar with the following:

  • The Visual Studio IDE

  • The C++ programming language


For more information, see:

System Definition Model (SDM)

You can use Distributed System Designers to create and maintain a set of interrelated diagrams and documents that are based on the System Definition Model (SDM). Typically, the definitions created in one document (application definitions, for example) are referenced by other documents.

Visual Studio Team Edition for Architects includes a template that lets you create a distributed system solution. This distributed system solution makes Distributed System Designers available so that you can design, configure, connect, and evaluate deployment for applications and application systems.

As a distributed system solution is developed, it typically will contain the following items:

  • A single application diagram (.ad file).

  • One or more system diagrams (.sd files).

  • One or more logical datacenter diagrams (.ldd files).

  • One or more deployment diagrams (.dd files).

  • SDM documents (.sdm files) for externally implemented application definitions.

  • Projects that contain code files, configuration files, other related files, and SDM documents for internally implemented application definitions.

For more information, see:

Team Foundation Server Extensibility and SDK

Team Foundation Server lets team members participate in development project workflow while they are working in the IDE. You can customize and extend Team Foundation Server to meet the specific needs of your development team.

The Team Foundation Administrator's Guide in the Team Foundation Server Help documentation shows how to customize Team Foundation Server functionality by modifying XML schemas. The Team Foundation Server SDK shows how to extend Team Foundation Server functionality by writing code. Before you write code to access the object models described in the Team Foundation Server SDK, you should become familiar with the customization techniques. You might discover that customization gives you all the extensibility that you need.

The Visual Studio Team Foundation Server SDK includes documentation and samples to help you develop software products that integrate with Microsoft Visual Studio 2005 Team Foundation Server. This documentation applies to the released versions of Visual Studio 2005 and Team Foundation Server.

For more information, see:

See Also