Windows 7 Service Pack 1是否已破坏基于ADO的COM +应用程序 [英] Has Windows 7 Service Pack 1 broken ADO based COM+ Applications
问题描述
这是"Windows 7 Service Pack 1中MDAC ADODB组件的突破性更改"中的响应重新发布。线。 （有些受访者认为应该采用不同的方式）
COM +问题！
我不确定是否这属于这里或新线程，但我确信问题是相关的。我们有许多基于VB6 COM +的旧应用程序，它们最初是作为NT应用程序编写的，但在XP客户端/ Win2003服务器环境中运行良好，并且在这里和那里进行了奇怪的调整。我们打算很快改变我们的客户端环境，并且去年年底我使用Windows 7 32位RTM客户端（具有相同的Win2003后端）对其中一些应用程序（使用相同的可执行文件）进行了一些初步测试。
一切似乎都很好。
本周（认为这是肯定的）我开始使用Windows 7 SP1测试其中一个。令我惊讶的是，应用程序几乎没有启动，我收到了"自动化错误 - 未找到元素"。我检查过我没有犯过任何安装错误。我重新检查了
，相同的程序同时适用于XP和Windows 7 RTM。我将生成SP1错误的代码中的行跟踪到创建COM +应用程序中的对象的位置。奇怪的是，在初始化期间已经成功创建了另一个COM +对象（在不同的应用程序中）
。这两个对象之间的区别在于后者引用了Microsoft ActiveX Data Objects Recordset 2.8库。
为了确认这是问题，我创建了一个最小的测试COM +库和客户端在XP机器上的VB6程序。这引用了相同的库，但仅使用它来允许在客户端和服务器之间传递记录集（从未实际使用过
）。果然这个组合在XP，Windows 7 RTM但不是Windows 7 SP1中运行良好。正如我所提到的，我们在这个体系结构上构建了几个重要的应用程序，因此这可能会导致我测试库包含以下代码的
'------------------------- --------------------
Public Sub testString（ByRef referenceText As String）
   referenceText ="通过COM +更新"
End Sub
公共函数testRecordset（ByRef myRecords As Recordset）As Boolean
testRecordset = True
结束函数
'---------------------- ---------------------
这是一个名为clsW7SP1ADOProblem的类文件，其实例化设置为MultiUse，TransactionMode设置为UsesTransactions。该类在一个名为W7SP1ProblemDemoLib的ActiveX DLL中编译。然后将编译的DLL作为新组件添加到
Windows 2003服务器上的新COM +应用程序，然后导出代理。客户端应用程序只是一个包含两个按钮的表单，其中包含以下代码：
'---------------------- --------------------------
Private Sub Command1_Click（）
  Dim testlib As W7SP1ProblemDemoLib.clsW7SP1ADOProblem
Dim paramtext As String
设置testlib = New W7SP1ProblemDemoLib.clsW7SP1ADOProblem
testlib.testString paramtext
MsgBox paramtext，vbOKCancel，"Reference Text"
设置testlib = Nothing
End Sub
Private Sub Command2_Click（）
Dim testlib As W7SP1ProblemDemoLib.clsW7SP1ADOProblem
作为记录集的暗淡记录
昏暗的结果作为布尔
设置testlib = New W7SP1ProblemDemoLib.clsW7SP1ADOProblem
result = testlib.testRecordset（records）
MsgBox结果，vbOKCancel，"参考文本"
设置testlib = Nothing
End Sub
'--------------------- -----------------------
客户端应用程序引用测试库并引用Microsoft ActiveX数据对象记录集2.8库以便处理记录集参数。已编译的客户端和COM +代理在所有三个客户端上手动安装（XP，Windows
7 RTM和Windows 7 SP1）。在前两种情况下，单击任一按钮将显示预期的对话框。在SP1上，在任何一种情况下都会出现"自动化错误 - 未找到元素"消息。第一个调用甚至不涉及ADO参数，但是来自早期的
帖子我猜测仅仅存在ADO库引用导致问题。
请任何人解释这里发生了什么，这是否与之前帖子中描述的其他事件有关，并且希望我们可以做些什么来解决这个问题。
谢谢。
（注意 - 所有代码都是在Windows XP上的Visual Studio 6中编译的）
<那有没有人分享这个问题？我注意到我的帖子已经被大约一百个人阅读了，但是这个帖子上没有回复，只有关于代码在原始帖子上编译的位置的查询。还有其他人还有
有基于COM +应用程序的VB6系统使用ADO吗？我想很多那些人现在都不打算转向Windows 7。但是，如果他们打算这样做，那么看起来这可能会让他们感到愤怒。
只是为了在编译和运行时环境中绝对清楚：
- 所有代码都是使用Windows XP Service Pack 2上的Visual Basic 6.0编译的。
- Com +应用程序是在Windows 2003 Server Service Pack 1上的组件服务中创建的，并且是一个应用程序从该服务器生成代理
- 在Windows XP Service Pack 3和Windows 7 RTM
上安装（使用COM +应用程序代理）时客户端运行没有问题- 客户端在Windows 7 SP1中直接安装或机器升级时出错。
我会非常感谢任何回复（如果只是为了保证自己不会生气）。
感谢。
This is a repost of a response in the "Breaking change in MDAC ADODB components in Windows 7 Service pack 1" thread. (Some respondents felt it should be in a different thread)
COM+ Problem!
I'm not sure whether this belongs here or in a new thread, but I am sure the problem is related. We have a number of old VB6 COM+ based applications which were originally written as NT applications but have served well in an XP client / Win2003 server environment with the odd tweak here and there. We are intending to change our client environment soon and I had done some initial testing of some of these apps (using the same executables) with a Windows 7 32-bit RTM client (with the same Win2003 backend) late last year. All appeared to be fine.
This week (thinking it would be a sure thing) I started testing one of these using Windows 7 SP1. To my surprise the app had barely started and I got an 'automation error - element not found'. I checked that I had not made any installation mistakes. I rechecked that the same procedure worked on both XP and Windows 7 RTM, which it did. I tracked down the line in the code that generated the SP1 error to where an object in COM+ application was being created. Strangely however another COM+ object (in a different application) had already been created successfully during the initialisation. A difference between these two objects was that the latter referenced the Microsoft ActiveX Data Objects Recordset 2.8 Library.
In order to confirm that this was the problem I have created a minimal test COM+ library and client program in VB6 on an XP machine. This references the same library but only uses it to allow a recordset to be passed between the client and server (it is never actually used). Sure enough this combination works fine in XP , Windows 7 RTM but NOT Windows 7 SP1. As I mentioned we have several significant applications built on this architecture so this could causes us very major problems. The test library consists of just the following code
'---------------------------------------------
Public Sub testString(ByRef referenceText As String)
referenceText = "Updated via COM+"
End Sub
Public Function testRecordset(ByRef myRecords As Recordset) As Boolean
testRecordset = True
End Function
'-------------------------------------------
This is in a class file called clsW7SP1ADOProblem which has instancing set to MultiUse and TransactionMode set to UsesTransactions. The class is compiled in an ActiveX DLL called W7SP1ProblemDemoLib. The compiled DLL was then added as a new component to a new COM+ application on a Windows 2003 server and the proxy then exported. The client application is just a form with two buttons that contains the following code:
'------------------------------------------------
Private Sub Command1_Click()
Dim testlib As W7SP1ProblemDemoLib.clsW7SP1ADOProblem
Dim paramtext As String
Set testlib = New W7SP1ProblemDemoLib.clsW7SP1ADOProblem
testlib.testString paramtext
MsgBox paramtext, vbOKCancel, "Reference Text"
Set testlib = Nothing
End Sub
Private Sub Command2_Click()
Dim testlib As W7SP1ProblemDemoLib.clsW7SP1ADOProblem
Dim records As Recordset
Dim result As Boolean
Set testlib = New W7SP1ProblemDemoLib.clsW7SP1ADOProblem
result = testlib.testRecordset(records)
MsgBox result, vbOKCancel, "Reference Text"
Set testlib = Nothing
End Sub
'--------------------------------------------
The client app references the test library and also references the Microsoft ActiveX Data Objects Recordset 2.8 Library in order to handle the recordset parameter. The compiled client and the COM+ proxy were installed manually on all three clients (XP, Windows 7 RTM, and Windows 7 SP1). In the first two cases clicking either button displays the expected dialog. On SP1 the 'automation error - element not found' message appears in either case. The first call does not even involve an ADO parameter but from earlier posts I am guessing that the mere presence of the ADO library reference is causing the problem.
Please can anyone explain what is going on here, whether this is related to the other incidents described in earlier posts, and, hopefully, what we can do to workaround the issue.
Thanks.
(NOTE - all code was compiled in Visual Studio 6 on Windows XP)
Does anyone out there share this problem? I note that my post has been read by around a hundred people but there have been no replies on this thread and only an enquiry about where the code was compiled on the original thread. Does anybody else still have VB6 systems based around COM+ applications that use ADO? I guess a lot of those who do are not looking to move to Windows 7 at the moment. However, if they ever intend to, it would appear that this could bite them.
Just to be absolutely clear on the compile and runtime environments:
- All code was compiled using Visual Basic 6.0 on Windows XP Service Pack 2.
- The Com+ application is created in component service on Windows 2003 Server Service Pack 1 and an application proxy is generated from that server
- The client runs without problem when installed (with the COM+ application proxy) on Windows XP Service Pack 3 and Windows 7 RTM
- The client errors when either it is installed directly in, or the machine is upgraded to, Windows 7 SP1.
I would be very grateful for any response (if only to assure myself I am not going mad).
Thanks.
这篇关于Windows 7 Service Pack 1是否已破坏基于ADO的COM +应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
