无法从 COM+ 导出 32 位 ServicedComponent使用 Windows 7 或 Windows Server 2008 64 位的目录
使用 Windows 2003 Server 或 2000，生成在另一个系统上使用的 COM+ 应用程序代理，包括在导出期间创建的 MSI 包内的 .NET Enterprise Services 组件。 .NET 组件也在 GAC 中注册，并且 regsvcs 在应用程序代理安装期间自动运行。
然而，我们发现Windows Server 2008不包含该程序集。它将包含 .tlb 但不包含 .dll，也不将其安装在 GAC 中，当然，当应用程序找不到程序集时，一切都会崩溃。
有人知道该怎么做才能确保这种行为像 2000-2003 年那样有效吗？
更新 我们可以仅使用 .NET 程序集生成代理，并且工作正常，但如果我们尝试将其他程序集或旧版 VB6 COM+ dll 添加到同一个包中，它会说它们是为不同的版本构建的处理器。
更新 据我所知，如果您在任何 CPU 模式下构建（所有项目都设置为该模式），那么当您通过将程序集拖放到组件服务应用程序中进行注册时，如果它是现有的，它将使用 64 位64 位应用程序。然而，这是一个 32 位应用程序。 COM+ 应用程序中注册了 VB6 dll，它们是 32 位的。因此应该使用 32 位注册表等...，并使应用程序成为 32 位。因此，当添加 .NET Any CPU 程序集后，它应该是 32 位...但是，当我们导出应用程序时，.NET 程序集不会添加到创建的 .MSI 中。
更新我们发现http://support.microsoft.com/kb/924729 其中讨论了无法导出 32 位 ServicedComponents 的错误...有一个修补程序，但它适用于 Windows Server 2003。我们已经缩小了问题范围，只有 32 位 ServicedComponents 无法正确导出。
Using Windows 2003 Server or 2000, generating a COM+ application proxy for use on another system, includes .NET Enterprise Services components within the MSI package created during export. The .NET components are also registered in the GAC and regsvcs runs automatically during installation of the application proxy.
However, we have discovered that Windows Server 2008 does not include the assembly. It will include the .tlb but not the .dll, nor install it in the GAC, and of course everything blows up when the application cannot find the assembly.
Anyone know what to do to ensure the behaviour works as it does in 2000-2003?
UPDATE We can generate a proxy with just the .NET assembly, and it works fine, but if we try to add other assemblies or legacy VB6 COM+ dlls to the same package it says they were built for a different processor.
UPDATE I understand that if you build in Any CPU mode (which all projects are set to), then when you register by dropping your assemblies into the Component Services application, it will use 64 bit if it's an existing 64-bit application. However, this is a 32-bit application. There are VB6 dlls that are registered in the COM+ application, which are 32-bit. So that should use the 32-bit registry etc..., and cause the application to be 32-bit. So when a .NET Any CPU assembly is added after, it should be 32-bit ... however when we export the application the .NET assembly doesn't get added to the .MSI which is created.
UPDATE We have found http://support.microsoft.com/kb/924729 which discusses a bug where 32-bit ServicedComponents cannot be exported ... there is a hotfix, but it is for Windows Server 2003. We have narrowed the problem down and it's only 32-bit ServicedComponents that are not exporting properly.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
编译到任何 CPU 的 .NET dll 在进行 jit 编译时都会呈现一定的位数。 COM+仅具有硬比特感。 x86 或 x64，但不是中性的。因此，您需要使用两者之一，而不是任何 CPU。
伯爵
.NET dlls compiled to any cpu will take on a bitness when they are jit compiled. COM+ only has a sense of hard bitness. x86 OR x64, but not neutral. For this reason, you need to use one of the two and not Any CPU.
Earl
MS 针对 2008r2 的此问题提供了修补程序。去年我们让他们确认这是一个错误并发布了修补程序。尝试联系他们以获取 HF。
MS has hotfix for this issue for 2008r2. We were able to get them to confirm it as a bug and release a hotfix last year. Try contacting them to get the HF.
我已经就此事与微软技术支持联系。问题是您无法在 Windows 2008 64 位上正确地从 COM+ 应用程序导出任何 32 位 ServicedComponent，因为注册表和目录的方式已更改。这也是 Windows Server 2003 上的问题，但已通过修补程序修复，并在 Windows Server 2008 64 位中标记为已修复，但实际上在 2008 年并未修复。这也是 Windows 7 中的错误。
所有 Windows 7 关心此问题的开发人员应联系 Microsoft 技术支持以报告他们遇到此问题，因为 Microsoft 无意在没有客户证明成本合理的情况下修复此问题。我们正在努力让微软接受我们的商业案例作为理由。如果将来有任何变化，我会更新这篇文章。
I have been in contact with Microsoft technical support about this. The problem is that you cannot export ANY 32-bit ServicedComponent from COM+ applications, properly, on Windows 2008 64-bit, because of the way the registry and catalog have changed. This was a problem on Windows Server 2003 as well, but was fixed by a hotfix, and was marked as fixed in Windows Server 2008 64-bit, but actually was NOT fixed in 2008. This is also a bug in Windows 7.
All Windows 7 developers who care about this issue should contact Microsoft technical support to report that they are experiencing this issue, as Microsoft has no intention of fixing this without a cost justification from a customer. We are in the process of trying to get MS to accept our business case as justification. I will update this post in the future if anything changes.