Search

ADO programs no longer work on customer computers after recompiled on a Windows 7 SP1 machine by Sheng Jiang 蒋晟

Closed
as Fixed Help for as Fixed

36
0
Sign in
 to vote
Type: Bug
ID: 646313
Opened: 2/22/2011 8:17:49 PM
Access Restriction: Public
5
Workaround(s)
24
User(s) can reproduce this bug
The original forum post is at http://social.msdn.microsoft.com/Forums/en/windowsgeneraldevelopmentissues/thread/3a4ce946-effa-4f77-98a6-34f11c6b5a13 but the scope of the issue is wider, a development machine with KB 983246 would generate code incompatible with machines without kb983246, which only supports Windows XP SP3 and Windows 2003 SP2 or higher. I decided to make this question more trackable and have a place to vote on its priority.

I know the need to fix the type library for 64bit developers. But I still suggest Microsoft to at least better inform developers. The title of the KB article "Type Mismatch" error message when you run a VBA macro in a 64-bit version of an Office 2010 application" does not show how wide the problem is.
Details (expand)

Visual Studio/Silverlight/Tooling version

Visual Studio 2010

What category (if any) best represents this feedback?

Compatibility

Steps to reproduce

Make a program that references the pre-kb983246 type library
Install kb983246 (which is included in Windows 7 SP1)
Recompile program

Product Language

English

Operating System

Windows 7

Operating System Language

English

Actual results

for programs contains early binding code that depends on the ADO type library (e.g. VB6 programs who use the ADODB Data Controls), the compilation would fail.

for programs that load ADO at run time using early binding (e.g. people who use #import statement to import the msado15.dll in Visual C++) the generated code would only work on machines with kb983246.

Expected results

Add SDK documentation on the breaking change, and if it is going to be breaking change in the ADO dual interfaces in the future, demostrate how to use version-dependent interfaces.

I guess programmers who needs to support customers running Windows XP SP2, Windows 2003 SP1 and earlier systems already have the old version of msado15.dll file on the test machine so there is no need to make the old type library downloadable.
File Attachments
0 attachments
Sign in to post a comment.
Posted by zhiyazw on 2/16/2012 at 11:59 PM
Consider the latest fix, in my team project, there are both win7 users and xp users, win7 users need to #import msado60.tlb, while xp users need to #import msado15.dll. And this is an open project, we are not in a single company, and team members are variational, a member may join today and a member may quit next month, it's almost impossible to ask them to use a consistent OS, how can I configure the project in this case?
Posted by Microsoft on 2/14/2012 at 9:22 PM
Announcement:

We have just published the fix for Win7 SP1 and Win Server 2008 R2 SP1. Please download and install the KB from http://support.microsoft.com/kb/2640696 (also, please read the section "Update Information" carefully). This fix is very similar to the Win8's fix; so if you can work well with the Win8 fix, it is very likely that the new fix can work for you as well.

In case if you encounter any issues with the new fix, please post the detail steps to reproduce the issue in the forum: http://social.msdn.microsoft.com/Forums/en-NZ/windowsgeneraldevelopmentissues/thread/280de88a-77dd-455e-9797-b28928206e38. Or if it is an urgent issue blocking your business, please file a new request to our customer support team.


Thanks,
Ming.
WDAC Team, Microsoft.

Posted by Shuhai on 12/15/2011 at 11:06 PM
Hi Stanley.k, they both mean OSes. 32-bit Computer = 32 bit OS, and AMD64 Computers and IA computers = AMD64 and IA version of Windows.
Posted by Stanley.k on 11/9/2011 at 11:59 PM
The article do not explain it clearly.
For 32-bit computers - is this a 32 bit cpu or 32 bit OS?
For AMD 64 computers and For IA64 computers - is this a 64 bit cpu running a 32 bit OS or 64 bit OS?
Posted by Stanley.k on 11/9/2011 at 9:14 PM
Can microsoft make all things simpler by providing us a reg file and automation procedure instead?
Posted by carlk4574 on 8/31/2011 at 7:19 AM
Anything new on a fix? This is incredibly inconvenient for my VBA development team.
Posted by Daniel Castenholz on 5/22/2011 at 9:52 PM
Can we please get an ETA on the fix.
Posted by Microsoft on 4/28/2011 at 12:18 AM
Announcement:

Microsoft has just decided to stop the download of the original KB at: http://support.microsoft.com/kb/983246. The download link will be removed in a few days and the KB will be slightly modified with a warning message.

Customers should not download the original KB. If you have already downloaded the KB, we suggest you to uninstall the KB first.

Sorry for any confusion and extra work that you have already spent on this issue. We will release a new KB later.
(As mentioned above, I cannot communicate any technical detail or date of our plan, sorry about that. But this is still our top priority work)

Thanks,
Ming.
WDAC Team, Microsoft.
Posted by John Walker on 4/19/2011 at 11:36 PM
This is a critical bug for our company. I understand that a fix is in the works, but I'm adding my this comment in the hope that it reinforces the need for a *true* fix very soon.
Posted by Microsoft on 4/6/2011 at 11:27 PM
We have just released a new version of the KB: http://support.microsoft.com/kb/2517589 which provides a new workaround to the issue. This can be viewed as a temporary solution to the issue (for C++, VB6 and VB.NET customers only). Although this is temporary, this should work forever if you chose this workaround, since the downloaded typelib is basically the same as the one shipped in Win7 RTM (with LIBID changed, so you can see two entries in the "Add Reference" dialog). This is suitable for those customers who would like to use Win7 SP1 as a development platform.

Unfortunately, the workaround cannot work for VBA scenario.

We understand this can still cause some inconvenience to customers since you need to change the referenced typelib, and this does not work for VBA customers. But this is the fastest solution that we can provide to temporarily resolve this issue. And we are still working on a longer-term solution which may take more time.

Regards,
Ming.
WDAC Team, Microsoft.
Posted by Steven Thebo on 3/30/2011 at 7:08 AM
This is a huge critical issue for many developers. Every VB6 app (yes, many still exist in the real world, MS) that I am supporting has been adversely impacted by this at multiple clients. It took days to find the forum entries that were relevent to the problem. Now I see MSFT has not even bothered to post any updates in over a week.

I finally decided to dump Windows 7 for MY soloution. Thanks MSFT

Hey remember when you used to hae a very loyal developer community? Guess those days are gone.
Posted by Pak-Ming Cheung on 3/20/2011 at 10:24 PM
KB: http://support.microsoft.com/kb/2517589
Posted by Pak-Ming Cheung on 3/20/2011 at 10:23 PM
Our team has just published a KB to summarize the current issue.
In the meantime, we are still working on whether there is any better workaround for the issue.
Posted by Chris Conti on 3/18/2011 at 1:01 PM
Added a workaround that seems to resolve my issue with c# source compatibility.
Posted by Chris Conti on 3/16/2011 at 5:37 AM
I should clarify that the problem I'm describing in my previous comment is one of source compatibility. The existing c# code simply will not compile on a system with SP1/KB 983246 installed.
Posted by Chris Conti on 3/16/2011 at 5:25 AM
As Adzm points out as a workaround, #import with an older version of the .tlb can work around some issues, but I have been unable to find any description of a workaround that works with managed code, short of uninstalling SP1/kb983246 or manually overwriting the tlb. tlbimp.exe appears to give insufficient control over the import process.

The specific scenario I am dealing with involves using tlbimp on a type library that contains an interface which has a method that returns a recordset (not the greatest interface, but since you're kind of stuck once you publish...):
...
interface IFoo
{
HRESULT GetData([out,retval] _Recordset** pRS);
}
...
Since there appears to be no way to control where tlbimp will load indirectly referenced tlbs from, on an SP1 system, tlb will always generate a reference to a type named ADODB._Recordset_Deprecated (even if I create my own ADODB instead of using the PIA)
Posted by Microsoft on 3/13/2011 at 6:55 PM
Our team is preparing a more specific KB to talk about this issue.
Posted by Peter R Fletcher on 3/3/2011 at 11:57 AM
This is a major problem for developers who develop software for use on machines that are not at the OS cutting edge - i.e. almost anyone who has users outside his/her own office!!
Posted by Andy Steinmann on 3/1/2011 at 6:25 AM
FYI this occurs when using Binary Compatibility for files across two systems (one with SP1 and one without).
Posted by Microsoft on 2/22/2011 at 9:14 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.
Posted by Adzm on 3/4/2011 at 8:11 AM
With C++, your only hope is to #import an old version of the tlb / dll.
Posted by Chris Conti on 3/18/2011 at 1:00 PM
from my posts at http://social.msdn.microsoft.com/Forums/en/windowsgeneraldevelopmentissues/thread/3a4ce946-effa-4f77-98a6-34f11c6b5a13:

For C++, the following seems to be working for me, to preserve both binary and source/compilation compatibility (replace the path as appropriate for your environment):

1. Get a copy of msado15.dll from a down-level system into \Common\3rdParty\ADO_old\ (do not register it)

2. in .h/.cpp files replace:

#import "msado15.dll" rename("EOF", "adoEOF")

with:

#import "\Common\3rdParty\ADO_old\msado15.dll" rename("EOF", "adoEOF")

3. in IDL files replace:

importlib("msado15.dll")

with:

importlib("\Common\3rdParty\ADO_old\msado15.dll")

4. if you #import a typelibrary that exposes a recordset/connection/etc. as a parameter replace:

#import "MyStuff.tlb"

with:

#import "MyStuff.tlb" \
    inject_statement("#define _Recordset_DeprecatedPtr _RecordsetPtr")\
    inject_statement("#define _Recordset_Deprecated _Recordset")
[add a pair of inject_statement parameters for each ADO type name that is marked as deprecated]



For managed code, to generate the RCW you need to manually invoke tlbimp:

tlbimp /tlbreference:"\Common\3rdParty\ADO_old\msado15.dll" MyStuff.tlb
Posted by Pak-Ming Cheung on 3/20/2011 at 10:24 PM
Please see the workaround section from the KB: http://support.microsoft.com/kb/2517589
Posted by Pak-Ming Cheung on 4/6/2011 at 11:28 PM
Please see the new workarounds from the KB: http://support.microsoft.com/kb/2517589
Posted by AndrasP on 4/17/2012 at 12:10 AM
Hello

I tried this Solution (kb983246) but unfortunatly it seems not to work !

I installed the kb983246 on my windows7 64Bit System and selected Objects 6.0 and lib 6.1 in "Projekte"Verweise"
after recommpiling and reinstalling on a Xp Sp1 system it still comes with a "Type missmacth Error2

Any suggestion what else I can to ??

best regards
Andreas
© 2012 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement