Share via

Registering a Registry-Based DDEX Provider

  • Article

You can implement a DDEX provider that is not based on a package and that provides basic design-time support by using the Windows registry to identify the provider and locate the appropriate code base.

The Registry-Based Scenario

Unlike in DDEX 1.0, in the new version of DDEX the registry-based provider is not confined to ADO.NET providers and supports all types of providers. However, the most common DDEX provider implementation involves an ADO.NET provider that requires only basic design-time support. For example, your application may need to provide some custom data-source connection user interface (UI), but do nothing complex, like providing custom designers. In such a case, authoring a full-scale implementation of a VSPackage is not necessary. Rather, you can provide explicit references to your provider components by using the Windows registry.

Registering the Provider

To register your implementation of a provider that is not based on a package, do the following:

1. Generate a GUID for the DDEX Provider

A GUID provides a unique identifier for your provider in the application context.

2. Add GUID to Registry Key

Enter your provider GUID in the DataProviders key of the application's local registry hive. This entry might look like the following example:

HKLM\SOFTWARE\Microsoft\VisualStudio\9.0\DataProviders\{11111111-1111-1111-1111-111111111111}

3. Add Values to the Key

Add the appropriate DDEX provider values to the DataProviders registry key. The key contains seven fields, as follows:

(Default)

Name of the provider (for registry purposes).

AssociatedSource

The GUID of the data source that this DDEX provider is associated with.

CodeBase

The path to the DDEX provider assembly file. For example, this field can be set to "C:\MyDDEXProvider\bin\Debug\ProviderWithUICustomization.dll".

Description

Pointer to a string resource in an assembly that contains a description for the provider, in the form "StringName, ResourceName, Assembly". If the assembly value is not specified, the implementation defaults to the assembly specified for the Codebase value.

DisplayName

Pointer to a string resource in an assembly that contains a display name for the provider, in the form "StringName, ResourceName, Assembly". If the assembly value is not specified, the implementation defaults to the assembly specified for the Codebase value.

InvariantName

The invariant name of the ADO.NET provider.

PlatformVersion

The version of the DDEX component used. Use "1.0" for Visual Studio 2005 SDK or use "2.0" for Visual Studio 2008 SDK and later.

ShortDisplayName

Pointer to a string resource in an assembly that contains a short display name for the provider, in the form "StringName, ResourceName, Assembly". If the assembly value is not specified, the implementation defaults to the assembly specified for the Codebase value.

Technology

The GUID specifying ADO.NET technology: {77AB9A9D-78B9-4ba7-91AC-873F5338F1D2}

4. Specify Supported Objects

DDEX providers must also include in the registry an indication of which objects they support. They must do this for two reasons:

  • The DDEX engine, as well as clients, must be able to determine the capabilities of a given provider without needing to load the provider's assembly.

  • In some cases, it is necessary for the provider to provide information about how to instantiate or implement one or more of the supported objects.

To indicate which objects are supported, a provider must do the following:

  1. Add a SupportedObjects key under the DDEX provider key in the registry.

  2. Add a registry key for each of the objects supported by the DDEX provider. Although there are no required objects, it is recommended that you add the following two objects for the provider to be meaningful:

    1. IVsDataConnectionProperties. Implemented by using the DbConnectionStringBuilder class.

    2. IVsDataConnectionSupport. Implemented by using the IDbConnection interface and features of the DbConnection class, where available.

  3. Add additional keys for additional supported objects. For each of these, provide the name of a managed type that provides the implementation as the Default value of the key. This name is automatically scoped in the assembly specified by the Codebase value, but it can also be a fully qualified type name including assembly details. Following are additional keys that you can specify for your additional supported objects:

    1. IVsDataConnectionPromptDialog

    2. IVsDataConnectionProperties

    3. IVsDataConnectionSupport

    4. IVsDataConnectionUIControl

    5. IVsDataObjectIdentifierConverter

    6. IVsDataObjectIdentifierResolver

    7. IVsDataObjectMemberComparer

    8. IVsDataObjectSupport

    9. IVsDataSourceInformation

    10. IVsDataViewSupport

Note that IVsDataObjectSupport and IVsDataViewSupport keys provide the location of the respective XML files. (See DDEX Data Object Support and DDEX Data View Support for more information.) These can be specified directly, as a path to a file location on disk, or as a pointer to a resource in a specified assembly. This eliminates needing to implement these classes to manually provide an XML stream.

Note, too, that for the DataSourceInformation key, you can insert various name/value pairs. These can provide information about the static data source directly, without needing to provide code to implement the DataSourceInformation class.

5. Map to a Data Source

DDEX providers can be associated with DDEX data sources by using registry entries under the DataSources key in the application's local registry hive, for example, HKLM\SOFTWARE\Microsoft\VisualStudio\9.0\DataSources.

Each DDEX data source has an identifying GUID, along with corresponding display name and description strings supplied by a supporting provider.

For a new data source, you must do the following:

  1. Create a GUID identifier for the data source and place it in the registry under DataSources.

  2. Add a DefaultProvider value to this key, whose value is the GUID of the default DDEX provider for the data source.

For existing data sources and new data sources, you must do the following:

  1. Under the DataSources key, create a SupportingProviders key and populate it with a subkey for each DDEX provider that supports the data source.

  2. For one or more (minimum one) of the DDEX provider subkeys, enter a DisplayName value in precisely the same format as you entered for the DisplayName value under the corresponding DDEX provider's key.

  3. For each supporting provider, optionally provide a Description value in the same format as provided as the Description value for the corresponding DDEX provider. This description string should combine the selected data source and data provider into a single, meaningful statement, for example, "Use this selection to connect to a Microsoft Access data source by using the native Jet provider through the .NET Framework Data Provider for OLE DB."

See Also

Concepts

Registering a Package-Based DDEX Provider

Registering a DDEX Provider Specialized for OLE DB

Registering a DDEX Provider Specialized for ODBC

Other Resources

DDEX Provider Implementation