I am working on the DDEX provider for my job and testing it in 2010 B2 since a lot of our customers have decided to switch to it. When I tested in the first 2010 release, only the install failed due to a .net 4 assembly being laoded by a .net 2 runtime, once that was fixed everything worked.
In B2, however, I got the installer working, but now the provider crashes when trying to create or select a database. This is code that has not changed since before the last 2010 test and now fails? I think the .net 2.0 support in 2010 B2 is busted.
Well, I decided to fire up a VPC image and remote debug the code to see where it fails, well that was a pure fail situation. I cannot use 2008 remote debugger to debug any managed code running under 2010, even .net 2.0 code. It was then decided to just go ahead and install 2010 on my machine and try it that way.
After a horrendously long install and a reboot I loaded up my debugging environment and attempted to do a hive install. Again MS has decided to kick me in the nuts, 2010 does not use the registry for its experimental hive, unlike all previous verisons, though 2010 running normally does use the registry.
Now I have to research how to test in the new file system based hive. There are no registry keys used, and 2010 still requires regkeys to load a DDEX provider. Now what am I to do? After researching MSDN I foufn they provide a new tool to create pkgdef files that are supposed to contain the information to load a package. I hoped it also created the virtual regkeys necessary for the hive. I then went about adding the util to the build process so I could gen a build and a pkgdef file.
Fail again, the pkgdef tool cannot resolve an assembly, Microsoft.VisualStudio.Data, so it cannot create a pgkdef file! AAARRGGGHHH! WHY?!?!
Looks like I'll have to fall back to old school debugging and just log the hell out of the provider and troubleshoot that way.
At least I have Gibraltar to make the logging a bit easier, thank god for small favors.