Visual Studio is made of software modules called VSPackages. Tool windows, editors, services, and project types are all VSPackages. By creating your own VSPackages, you can add features to the Visual Studio Integrated Development Environment (IDE) for your own use, or for distribution to other users. The Visual Studio SDK includes tools, samples, and documentation to help you create VSPackages. You can use Visual C#, Visual Basic, or Visual C++ to write the code for your VSPackages. 

For more information, see

• Visual Studio Integration SDK Roadmap

• Tutorials for Customizing Visual Studio By Using VSPackages

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

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 help your organization model its specific business processes.

You can also use Domain-Specific Language Tools to build a state chart tool that describes 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 that you require in your tool.

For more information, see

• Domain-Specific Language Tools

• About Domain-Specific Languages

• How Do I in Domain-Specific Language Tools

• MSDN Webcast: Domain-Specific Development with Visual Studio DSL

Data Designer Extensibility (DDEX) lets you extend data designers in Visual Studio to communicate with many external data sources at design time, expose their object hierarchies, and show the hierarchies 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 DDEX SDK provides documentation, samples, and resources to help you implement a DDEX provider.

For more information, see

• Data Designer Extensibility Architecture

• Data Designer Extensibility (DDEX) SDK

Context sensitivity is a Help feature that lets Help authors and VSPackage developers work together to create relationships between Help topics and objects in the IDE. At run time, when 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.

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 when a user requests Help on a selected object.

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

For more information, see

• Help Integration Essentials

• Getting Started with Help Content and Integration

Visual Studio supports two kinds of source control integration. One kind is a source control plug-in that is built by using the Source Control Plug-in API (formerly known as the MSSCCI API) and provides basic functionality. The other kind is a VSPackage-based source control application 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 are provided through the API, and most operations are exposed through the Visual Studio user interface (UI). This approach is appropriate for most source control scenarios and is easier to implement than VSPackage-based source control is. However, the VSPackage-based approach, in which you develop the source control functionality and UI on your own, gives you more flexibility.

For more information, see

• Source Control Integration Overview

• Creating a Source Control Plug-in

• Creating a Source Control VSPackage

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 Team Foundation Server Help 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 that are 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 release versions of Visual Studio 2008 and Team Foundation Server.

For more information, see

• Team Foundation Server Extensibility

• Team Foundation Server SDK

The Visual Studio 2008 Debugging SDK provides information to help you customize Visual Studio debugger components or create your own debugger components to integrate into the IDE.

In Visual Studio, debugging is executed out-of-process with the program that is being debugged. Therefore, 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 use the Visual Studio 2008 Debugging SDK, you should be familiar with the following things:

• The Visual Studio 2008 IDE

• The C++ programming language

• ATL COM

For more information, see

• Getting Started (Visual Studio Debugging SDK)

Visual Studio Team Edition for Testers includes a suite of test tools that are closely integrated with Visual Studio 2008. 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 2008. 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

• How Do I in Test Edition

• Walkthroughs for Test Edition

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 that are 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.

For more information, see

• Distributed System Designer Overviews

• Relationships Between System Definition Model (SDM) Documents

Concepts

Other Resources