I have been looking for this information for some time. The fact that I could only find it tonight (when it has been published since May) is proof that there is not enough "hyperlink glue" among the words in the subject out there in the Web.
The sole purpose of this post is to provide some of this glue, so you can find the information more easily from now.
I once tried posting a question on Steve Lasker's team Smart Client Data blog:
What do I need to add to a custom ADO.NET provider to get design-time support in your tools?
But unfortunatelly my comments were deleted, likely by an anti-spam filter.
Just for the record: Once again, I think the tools provided by the Visual Studio Data Team (I don't recall the exact name of the team right now) are great, and I would say this to Steve Ballmer and Bill Gates if they asked me :)
But I am guilty of wanting more features and more openess in the development tools I use everyday.
Tonight I finnaly found a clue in this blog. There, someone talks about receiving some information from Microsoft on how to integrate a custom ADO.NET provider with Visual Studio. That someone does not actually uses the name Microsoft , but that very mature M plus a $ dollar sign thing. The post contains no link nor a detail about any API. It even says "ad.net" instead of ADO.NET. Now I cannot remember how I managed to find it!
A few minutes later, I got some inspired search string in Google (or was it MSN Search?). And here are the results!
So what is DDEX about? It is simple:
If you created your own "custom" ADO.NET 2.0 Provider and what it to be listed and exploited by the many design-time data tools in Visual Studio 2005 (like Server Explorer, Typed DataSet Designer, Data Sources, etc.) it wont be enough to add your provider to Machine.Config. You will need to create a "Provider Provider" using Data Designer Extensibility (DDEX).
I will probably be helping test this with an office mate tomorrow. He wrote our ADO.NET Provider.
No comments:
Post a Comment