Visual Studio ships with .NET data providers for SQL Server, Oracle and SQL Server Mobile Edition. That is certainly not an exhaustive list of .NET data providers. Several companies have built and are building providers for various databases (data sources). Why, you can write one too! (See: Creating a .NET Framework Data Provider.)

 

Now let’s say you use XML as a data source. You are building an app that uses XML as a data source and you use a .NET Data Provider for XML. Wouldn’t it be cool if you could connect to these databases in VS 2005 and have design-time support? We think so. DDEX provides a way to make that happen, quite easily.

 

What do you need to do? Well, that depends. J It depends on how much you want to extend. At one end of the spectrum you can have just basic support, while at the other you can go the whole nine yards: implement full DDEX features and a VS package.

 

At a minimum—for basic support—here’s what you need to do:

  • Create two XML files: MyDataObjectSupport.xml and MyDataViewSupport.xml
  • Register the provider as a DDEX provider

That’s it!

 

DDEX metadata engine includes a set of strongly typed classes that allow it to recognize generic objects like tables, views, and stored procedures, as well as generic properties on these objects. DataObjectSupport allows you to map Types that are supported by your provider to one of these generic concepts that are recognizable by the metadata engine. In this file you can specify what types the data source will support (tables, views, procedures, functions), and what their identifiers and properties are. In addition, you can also associate one or more actions with these types. An action specification includes at least a name (such as “Enumerate”), the class ID and the handler (such as: NamespaceFoo.Data.ObjectEnumeration) for that action. You can also specify a DSRef for the object. DSRef is the clipboard format used by data designers in VS. Objects that support DSRef can be dragged and dropped onto VS Data designers.

 

DataViewSupport defines the shape of the hierarchy in the data connections node of Server Explorer. This is where you define how the data source objects are shown in server explorer. You can define multiple views for the same data source. For instance, in Visual Studio we provide three views for SQL Server. For each node you can specify things like localized display names, command bindings (command name, clsid and handler), icons, etc.

 

These two xml files together define the enough to:

  • Define your server explorer hierarchy
  • Enumerate objects from your data source under the data connections node in server explorer
  • Allow drag and drop from server explorer to VS data designers

Naturally, if you want better support, such as your own connection control in the VS connection dialog, your own designers or custom commands and handlers, you would need to implement more DDEX API.

 

As I had mentioned in my last post, DDEX support will be available in VS 2005 beta 2. We will also have an SDK with a set of samples that demonstrate how to accomplish this.

 

In the mean time, do send me your feedback and let me know what you think of this.