Almost one year ago I wrote an article on my web site about how to show the Choose Data Source dialog of Visual Studio from you own code (an add-in, for example). It happens that the approach that I showed works only with the .NET data providers supplied with the .NET Framework (namely SQL Server, Oracle, ODBC and OLEDB), but not with 3rd party providers such as ODP.NET for Oracle, etc. In fact I knew that when I wrote the article but it was not until yesterday when I had to revisit it to use it. I spent several hours struggling with the Visual Studio implementation (which shows 3rd party .NET data providers) and finally I figured it out, so I have updated the article:

HOWTO: Using the Choose Data Source dialog of Visual Studio 2005 from your own code
http://www.mztools.com/articles/2007/MZ2007011.aspx

As you can see, it’s actually quite simple when you know how to do it, but if you have to investigate, the Visual Studio internal implementation is so complex as a DataProvider class that inherits from another class named DataProvider (yep, same name but from another assembly), which implements IVSDataProvider and if that is not enough you have another VSDataProvider class. And this mess repeats with another classes such as DataConnectionDialog, etc. I wonder if this is the kind of things that make VS so slow…  All this is caused because VS extends an independent implementation of the Choose Data Source dialog to inject VS-only registered DDEX providers (a DDEX is a design-time extension for an ADO.NET 2.0 provider). It would be much better to register the DDEX providers outside the Visual Studio registry key and make the Microsoft.Data.*.dll assemblies recognize 3rd party DDEX providers for the Choose Data Source dialog.

BTW, when you want to reference a Visual Studio assembly in the installation folder, MVP fellow Daniel Cazzulino has a great post about doing it without hardcoding its path. It would be great if VS did it automatically, but when he reported back to Microsoft, the engineer could not reproduce it. Too bad, because it is quite easy to reproduce the problem…you can vote for it in the link provided in that post.

Anyway, I think that the updated article solves completely the Choose Data Source dialog problem. Although DDEX came late to Visual Studio (it was not until 2005) we are seeing more and more 3rd party DDEX providers truly integrating inside Visual Studio, that is, using the Visual Studio Server Explorer instead its own explorer toolwindow (such as the Oracle Explorer of ODP.NET 10.x), and using the standard Choose Data Source dialog, etc. This is great news for Visual Studio!

Hi all,

I have started the new year with a MVP title for another year (thanks Microsoft!) and I have started to write more articles about Visual Studio extensibility. The one of today is about the folders that Visual Studio uses to locate .Addin files (XML registration). It happens that Visual Studio 2005 uses 5 folders by default and Visual Studio 2008 uses 6, and both allows you to add even more folders. I wonder why we should need more than one folder (to register an add-in for all users, which is the correct thing) and maybe another to register the add-in only for the current user (for development purposes only). But Microsoft thinks otherwise, and not surprisingly, the result is a mess. If you follow the MSDN Visual Studio 2008 documentation about this topic, you will find that:

• 1 location uses the hardcoded value “Application Data” that every non-English developer knows it is a sin.
• 3 locations are incorrectly documented. If you place the .AddIn file in the documented folder, the Add-in Manager won’t show it.
• 1 new location for Visual Studio 2008 is not documented. An even if it was, it happens that there is a bug in VS 2008 and it doesn’t work.

So, 6-1-3-1 = 1 folder, which is all we should need to register add-ins.

Furthermore, VS uses proprietary placeholders such as %VSCOMMONDATA% but there seems to be no API or registry entry to get that programatically, so your setup will have to use some workaround as explained in the article.

I wish developers don’t complicate things unnecessarily… the software would have less bugs…

Here is the article:

INFO: Default .AddIn file locations for Visual Studio add-ins
http://www.mztools.com/Articles/2008/MZ2008001.aspx