In using the preview releases of Visual Studio 2012, something that eventually became a stumbling block was missing .NET data providers in the IDE. The .NET components themselves can be manually registered in the toolbox, but if you want tooling support (for instance for strongly-typed datasets or EF) you need the data provider registered in the IDE.
At first I switched back to Visual Studio 2010 to do these specific tasks. One of the great features of Visual Studio 2012 is its file compatibility (project round-tripping) with Visual Studio 2010. However, after a few times of doing this I decided there had to be a better way.
I tried Googling around a bit, but most of the references I found were for how component developers can register their own data providers with the IDE. For me, though, the problem was getting data providers installed that don’t yet have support for the next version of Visual Studio.
My next intuition was to search the registry. So, I fired up regedit, accepting that lovely UAC prompt, and searched for the name of one of the data providers that was registered in Visual Studio 2010 but not Visual Studio 2012 – in my case Advantage Database Server.
In the end there were four relevant results in the following locations:
Under each of these keys are another series of keys with GUID names. Selecting a GUID key will show the details of the data provider (or data source) on the right.
So, to get this single data source & provider registered in the Visual Studio 2012 IDE, I ended up locating the four specific keys to my missing data source & provider (all had the same GUID name, but in each of the above locations), and exporting those registry entries to .reg files with the right-click context menu.
Then, I edited those four .reg files in Notepad, changing any references from “VisualStudio10.0″ to “VisualStudio11.0″. Finally, after saving, I double-clicked each of the four .reg files, accepting the small army of dialogs, and fired up Visual Studio 2012. Adding a new data source showed that the data providers were now registered and working.
I may end up writing a little utility for doing this with the ability to target any version of Visual Studio but, until then, the above steps are pretty simple (if not a little manual).
Update: Thanks to user ieaglle for pointing out that the HKLM paths will be different if you are running a 64-bit edition of Windows. The paths are: