A Better solution for the Windows 7 SP1 ADO GUID changes

  • Article

UPDATE: This fix was published in mid-February as https://support.microsoft.com/kb/2640696 . We are still working on fine-tuning all of the documentation so that everything points to the appropriate places, but the binaries are already available. The fixes for Windows 7 and Windows 2008 R2 and publically available. Fixes for other OSes are also available, but you will need to open up a support case to request them.

If you are still using ADO in some of your code and tried to upgrade your build machine to Windows 7 SP1, you probably ran into the fact that you cannot run code recompiled on Windows 7 SP1 on downlevel OSes unless you modify your references to point to the backward compatible type libraries from https://support.microsoft.com/kb/2517589. Unfortunately, the solution does not work in several scenarios of which the biggest is Visual Basic for Applications (VBA).

The GUID change itself was not really the big problem – in fact, if you have been developing against MDAC/WDAC for a while you probably remember the days when applications would only run on the MDAC version that it was compiled on or higher. When we stopped revisioning MDAC around the Windows 2003 SP2 days, the problem pretty much went away. Until recently…

What happened is that we realized that some of our ADO APIs used platform dependent data types. This caused problems when 64-bit applications tried to consume these platform dependent data types and the caller’s data type did not match that of the callee. https://support.microsoft.com/kb/983246 discusses a scenario where a VBA macro runs into this exact problem. Unfortunately, we drastically underestimated the number of customers who were recompiling ADO applications on Windows 7 SP1. Even worse, when I say drastically, I really mean DRASTICALLY.

As soon as we realized the magnitude of the problem, we started scrambling to come up with a better solution. At this point, though, our significantly less than ideal first attempt had compounded the problem because it had the potential to spread the changed GUIDs to downlevel OSes. At this point, we made the painful decision to pull https://support.microsoft.com/kb/983246. Yes – we recognized that it would leave some scenarios like VBA without a workable solution, but we deemed that a better option than continuing to spread the modified GUIDs. Although not ideal, our standing recommendations were to use either the backward compatible libraries from https://support.microsoft.com/kb/2517589 or to compile on Windows 7 RTM. While not covering every scenario, it covered the bulk of them and was the best option we could provide without massive re-architecting.

Now, I am happy to announce that we are coming out with a much better solution. We are going to do the following:

  1. Ship the 6.0 type library from Windows 7 RTM via the new type library file msado60.tlb.  This will ship for multiple platforms.
  2. Ship a new 6.1 type library (which contains both new and deprecated interfaces) and embed it inside the msado15.dll
  3. Revert back all 2.x type libraries to what they looked like in Windows 7 RTM.

Therefore, the 2.x and 6.0 type libraries can be used for backward compatible purposes, and the 6.1 type library can be used for 64-bit VBA solutions. If you find yourself in the enviable place of not having to do any downlevel OS support, you can migrate entirely to the 6.1 type library even for your non-VBA applications.

Although you can see this fix in action in the Windows 8 Preview we shipped in September, we won’t be able to deliver the Windows 7 SP1 fix until early next year. As you can imagine, we are checking and re-checking everything because we completely understand that the only thing worse than no fix at this point would be another incomplete fix that requires yet another direction shift and another significant delay. Also, we are hard at working making sure some other known issues with the Windows 7 SP1 WDAC build get addressed with this fix as well. These are as follows:

We are still working hard to try to deliver this fix even sooner than early next year, but at this point I am not making any promises for an earlier delivery.