am I the last to figure this out?

In my role with Sun I do quite a bit with the Visual Studio SDK.  I develop our ADO.NET provider and the integration code that allows the provider to work inside of Visual Studio.  We support VS 2005 and 2008 with a single binary and, up until now, I’ve used the VS 2005 SDK.  But I’ve had this nagging feeling that I should be able to use the 2008 SDK and the new VSCT format for producing the CTO files.

After some research I discovered that VS 2008 ships with some binding redirects that allows it to use binaries built with the 2005 SDK.  Of course you can always count on Microsoft to make this as hard as possible.  They could keep in mind that out here in the real world we have to support older VS versions and ship the SDK with all necessary tools and assemblies.  But this is Microsoft we are talking about so the regpkg tool that ships with the SDK and helps with assembly registration is tightly bound to the SDK version. 

But the stupidity doesn’t end there.  With some hacking you can get around the regpkg issue (and you can’t ship that tool anyway) but they don’t provide attributes to handle all the registration tasks that are necessary.  Need to register your assembly as a DDEX data provider?  Out of luck.  Need to specify the technology parameter so your DDEX provider works with the proper wizards?  Out of luck.  So, I don’t really give a flip about regpkg and the attributes.

With all that said, I tested building an integration project with the 2008 SDK after making the following changes.  The resources worked great originating as VSCT files. 

   1: <RegisterOutputPackage>false</RegisterOutputPackage>

   2: <RegisterWithCodebase>true</RegisterWithCodebase>

   3: <!-- Make sure we are 2005 compatible, and don't rely on RegPkg.exe 

   4:      of VS2008 which uses Microsoft.VisualStudio.Shell.9.0 -->

   5: <UseVS2005MPF>true</UseVS2005MPF>

   6: <!-- Don't try to run as a normal user (RANA), 

   7:      create experimental hive in HKEY_LOCAL_MACHINE -->

   8: <RegisterWithRanu>false</RegisterWithRanu>