I found today that Microsoft has violated the holy rules of COM and broken their msado15.dll. The violation occurs after the installation of Windows 7 Service Pack 1 (version 6.1.7601.17514).

What’s happened is Microsoft has changed a few function signatures due to a 64bit problem, and changed the class IDs while they are at it. Thus, backwards compatibility has been broken, making COM absolutely useless. Executables compiling on Windows7 SP1 will now only run on Windows7 SP1. We’ll have to assume that any other alternatives were carefully thought through and resulted in the world ending, because on face value this looks like a terrible fix.

In this epic saga spanning five months, we’ve still not reached a warm fuzzy conclusion. The best solution seems to be reverting this change made in the service pack and created a new set of 64bit functions. This would probably break all ADO code compiled in the last five months, but at least the last 15 years would work again.

In the meantime, here’s our official workarounds:

1. Use late binding. Because, you know, type safety and efficiency aren’t all that.
2. Uninstall Service Pack 1. I think they are laughing at us.
3. Temporary workaround for C++ developers. Yay!

So we’ll go for the only attractive option, #3. Details are here: http://support.microsoft.com/kb/2517589, but it basically boils down to installing and registering a file called “Msado60_Backcompat”, which is a truly ironic name if you remember what the whole point of COM is.

Except I’d deviate a little from the recommended steps, because forcing your team to install and register these files is a bit inefficient, and playing around in your common files location is plain nasty. There’s also no indication on how to swap them in and out for 32 and 64 bit builds. So here’s my lazy “it-just-works” method for Visual Studio 2010:

1. In your 3^rd party area of your source control, create a branch for Microsoft and Ado. Then branch off for the 64bit and 32bit versions, i.e.
   3rd Party

   =>Microsoft
   ====>Ado
   ======>x86
   ======>x64 

2. Download the 64 and 32 bit .tlb files, place them in their respective folders and rename them both to “msado60_Backcompat.tlb”.
3. Check these files in.
4. Open up properties for your project, and under C/C++, add the path to your tlb files.

   

   Add the path to the .tlb file to Additional Directories

   Don’t forget Release settings!

5. Do the same for your 64 bit version.
6. Change the #import "msado15.dll" part in your code to #import "msado60_Backcompat.tlb"
7. Recompile, build, wait for the next hotfix to come along and destroy your working programs.

Meanwhile, your programs will just work using COM black magic that nobody really understands.

I can only assume everyone who understands COM at Microsoft who could have prevented this fairly fundamental error from occurring has gone mad, senile or died. I know they are keen to get us all writing .NET code (I hear that’s what the cool kids are doing these days), but if no-one understands the technology that .NET is built on, we’re in trouble. I imagine in the near future, mythical COM developers will be held up in great esteem like a lost Mayan civilisation, revered as demi-gods with alien intelligence and magical powers. Or starving as unemployable geeks crying into their RSI-riddled hands.