Share via

Registering a Package-Based DDEX Provider

  • Article

The most common method of implementing a DDEX provider uses a VSPackage, providing the most robust and flexible design-time support. Using this implementation, the DDEX provider creates objects and resolves types and assemblies by using Visual Studio services that the DDEX provider identifies in the Windows registry.

Registering the Provider

To register your package-based provider implementation, 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 purposes of identifying it in the registry, for example, "SQL Server Data Provider" This value is not interpreted, assuming that a display name is located.

AssociatedSource

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

Description

Resource ID pointer to a string in an assembly representing 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

Resource ID pointer to a string in an assembly representing 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. This value can be a resource ID in the provider's satellite DLL.

FactoryService

A GUID specifying the Visual Studio service ID (SID) exposed by the DDEX provider's VSPackage that implements the IVsDataProviderObjectFactory interface. This must be registered as a standard Visual Studio service, so the same SID must be specified underneath the Services registry key.

InvariantName

The invariant name of an ADO.NET provider. Specify this value only if the underlying technology is ADO.NET, and some of the functionality is based on the base implementation obtained from the Microsoft.VisualStudio.Data.Framework.AdoDotNet namespace. These base implementations rely on the ability to discover the invariant name for the ADO.NET provider in order to create objects by using the DbProviderFactory class.

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

Resource ID pointer to a string in an assembly representing 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

A GUID specifying the underlying technology for this provider, if any.

4. Specify Supported Objects

DDEX providers must specify in the registry 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 may be necessary for the provider to provide information about how to instantiate or implement one or more of the supported objects.

The SupportedObjects key contains a set of child ID keys that indicate which DDEX support entities are supported, either by the factory service specified as the FactoryService value in the DataProviders key, or as a service on the DataConnection class. Essentially this includes all objects that are directly creatable using the CreateObject method and all objects that may be provided as services on the IVsDataConnectionSupport ServiceProvider implementation.

To indicate which objects are supported, do the following:

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

  2. Under the SupportedObjects key, add keys for objects that your provider supports. Following are examples of objects you can support:

    1. IVsDataConnectionPromptDialog

    2. IVsDataConnectionProperties

    3. IVsDataConnectionSupport

    4. IVsDataConnectionUIControl

    5. IVsDataObjectIdentifierConverter

    6. IVsDataObjectIdentifierResolver

    7. IVsDataObjectMemberComparer

    8. IVsDataObjectSupport

    9. IVsDataSourceInformation

    10. IVsDataViewSupport

Typically, no information under these keys is interpreted (although for OLE DB and ODBC there is some interpretation), but it is useful to set the default value of the key to the name of the interface.

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.

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

  4. 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.

  5. 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 combines 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."

Example

The following example provides registry entries for an IBM DB2 data provider that is registered inside the Visual Studio App ID (assuming that %REGROOTBEGIN% equals SOFTWARE\Microsoft\VisualStudio\9.0):

HKLM
{
   %REGROOTBEGIN%
 
   'DataProviders'
   {
      '{6085DDE2-2EE1-4768-82C3-5425D9B98DAD}' = s 'IBM DB2 Provider'
      {
         val 'DisplayName' = s 'Provider_DisplayName, IBM.DB2.Resources'
         val 'ShortDisplayName' = s 'Provider_ShortDisplayName, IBM.DB2.Resources'
         val 'Description' = s 'Provider_Description, IBM.DB2.Resources'
         val 'FactoryService'= s'{45E1413D-896C-4a2a-A75C-1CBCA51C80CB}'
         val 'Technology' = s '{6565551F-A496-45f3-AFFB-D1AECA082824}'
         val 'InvariantName' = s 'IBM.DB2'
         val 'PlatformVersion' = s '2.0'
 
         'SupportedObjects'
         {
            'IVsDataViewSupport'
            'IVsDataObjectSupport'
            'IVsDataConnectionUIControl'
            'IVsDataConnectionProperties'
            'IVsDataConnectionSupport'
         }
      }
   }
 
   'Services'
   {
      '{45E1413D-896C-4a2a-A75C-1CBCA51C80CB}' = s '{7B7F1923-D8F9-430f-9FA7-7919677E5EAC}'
      {
         val 'Name' = 'IBM DB2 Provider Object Factory'
      }
   }
 
   'Packages'
   {
      '{7B7F1923-D8F9-430f-9FA7-7919677E5EAC}' = 'DB2 Package'
      {
         val 'InProcServer32' = s 'mscoree.dll'
         val 'Class' = s 'IBM.DB2.DB2Package'
         val 'Codebase' = s '%MODULE%'
 
         'SatelliteDll'
         {
             val 'Path' = s '%PATH%'
             val 'DllName' = s 'IBM.DB2UI.DLL'
         }
   }
 
   %REGROOTEND%
}

See Also

Reference

DbProviderFactory

IVsDataProviderObjectFactory

IVsDataConnectionSupport