无法使用 Windows 7 或 Windows Server 2008 64 位从 COM+ 目录导出 32 位 ServicedComponent [英] Cannot export a 32-bit ServicedComponent from COM+ Catalog using Windows 7 or Windows Server 2008 64-bit

查看:26
本文介绍了无法使用 Windows 7 或 Windows Server 2008 64 位从 COM+ 目录导出 32 位 ServicedComponent的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

使用 Windows 2003 Server 或 2000,生成 COM+ 应用程序代理以在另一个系统上使用,在导出期间创建的 MSI 包中包含 .NET Enterprise Services 组件..NET 组件也在 GAC 中注册,regsvcs 在应用程序代理安装期间自动运行.

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.

但是,我们发现 Windows Server 2008 不包含该程序集.它将包含 .tlb 但不包含 .dll,也不会将其安装在 GAC 中,当然当应用程序找不到程序集时,一切都会崩溃.

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.

有人知道如何确保行为像 2000-2003 年那样正常吗?

Anyone know what to do to ensure the behaviour works as it does in 2000-2003?

更新我们可以只用 .NET 程序集生成一个代理,它工作正常,但是如果我们尝试将其他程序集或旧的 VB6 COM+ dll 添加到同一个包中,它会说它们是构建的用于不同的处理器.

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.

更新 我知道如果您在 Any CPU 模式下构建(所有项目都设置为该模式),那么当您通过将程序集放入组件服务应用程序进行注册时,它将使用 64 位,如果它是一个现有的 64 位应用程序.但是,这是一个 32 位应用程序.在 COM+ 应用程序中注册了 VB6 dll,它们是 32 位的.所以应该使用 32 位注册表等...,并使应用程序成为 32 位.因此,当之后添加 .NET Any CPU 程序集时,它应该是 32 位的……但是,当我们导出应用程序时,.NET 程序集不会添加到创建的 .MSI 中.

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.

更新我们发现 http://support.microsoft.com/kb/924729 讨论了无法导出 32 位 ServicedComponents 的错误......有一个修补程序,但它适用于 Windows Server 2003.我们已经缩小了问题的范围,只有 32 位 ServicedComponents 是未正确导出.

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.

推荐答案

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 7 或 Windows Server 2008 64 位从 COM+ 目录导出 32 位 ServicedComponent的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆