Export (0) Print
Expand All

DDEX Provider Registration 

DDEX providers use the Windows registry to expose their presence and to list the objects they support. However, various types of DDEX provider implementations do this differently. The topics in this section describe registration requirements for the four key DDEX provider implementations.

Because Visual Studio typically uses locally installed data providers, the installer does not need to register components. Instead, the underlying technology, like ODBC or OLE DB, normally provides the information need by data providers. However, installing a DDEX provider creates a different situation.

Because extra functionality is required to support DDEX inside Visual Studio, application installers are required to provide registry entries under the local registry root for App IDs that need to be supported by the provider. In cases where a given application is installed (devenv, for example), the provider is responsible for performing required additional steps, for example running devenv /setup.

NoteNote

Registration for DDEX providers is done under the Visual Studio local registry root.

Applications based on the Visual Studio IDE requires separate registration for each IDE instance. For example, if in addition to Visual Studio, you have also installed a workbench instance, such as the Business Intelligence workbench shipped with SQL Server, you need to register your DDEX provider in the registry root for each instance of Visual Studio or Visual Studio shell that you have installed.

In This Section

Registering a Package-Based DDEX Provider

This scenario is the most robust and best performing DDEX implementation, in which you create a VSPackage that implements Visual Studio services on behalf of the DDEX provider. This scenario provides virtually unlimited design-time support.

Registering a Non-Package-Based DDEX Provider

This scenario features an ADO.NET provider implementation that provides modest design-time support. This might include providing XML files, a specialized connection user interface (UI), a custom Server Explorer layout, as well as your own supported objects. It would probably not include features as ambitious as, for example, custom designers.

Registering a DDEX Provider Specialized for OLE DB

This scenario presumes that you have an available, standard OLE DB data provider that must be adapted for your DDEX implementation. The scenario requires that you provide XML or source file adjustments that specialize the OLE DB data provider to customize it specifically to your implementation.

Registering a DDEX Provider Specialized for ODBC

This scenario presumes that you have an available, standard ODBC data provider that must be adapted for your DDEX implementation. The scenario requires that you provide XML or source file adjustments that specialize the ODBC data provider to customize it specifically to your implementation.

Related Sections

DDEX Providers

Defines and discusses DDEX providers in the context of Visual Studio data extensibility.

Community Additions

ADD
Show:
© 2015 Microsoft