无法使用Windows 7或Windows Server 2008(64位)从COM +目录导出32位ServicedComponent

使用Windows 2003 Server或2000,生成用于其他系统的COM +应用程序代理,包括导出期间创build的MSI包中的.NET Enterprise Services组件。 .NET组件也在GAC中注册,regsvcs在安装应用程序代理期间自动运行。

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

任何人都知道该怎么做,以确保行为在2000 – 2003年那样工作?

更新我们可以使用.NET程序集生成一个代理,并且工作正常,但是如果我们尝试将其他程序集或传统VB6 COM + dll添加到同一个包中,则表示它们是为不同的处理器构build的。

更新我明白,如果你build立任何CPU模式(所有项目都设置为),那么当你通过将你的程序集放到组件服务应用程序来注册时,如果它是现有的64位应用程序,它将使用64位。 但是,这是一个32位应用程序。 有COM6应用程序中注册的VB6 DLL,它们是32位的。 所以应该使用32位registry等,并使应用程序是32位。 所以当一个.NET的任何CPU程序集添加后,它应该是32位…但是,当我们导出应用程序的.NET程序集不会被添加到.MSI创build。

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

Solutions Collecting From Web of "无法使用Windows 7或Windows Server 2008(64位)从COM +目录导出32位ServicedComponent"

MS有2008r2此问题的修复程序。 我们能够让他们确认它是一个错误,并在去年发布修补程序。 尝试联系他们获得HF。

编译为任何cpu的.NET dll在jit编译时会占用一定的位置。 COM +只有一点点硬的感觉。 x86或x64,但不是中性的。 出于这个原因,你需要使用两个之一而不是任何CPU。

伯爵

我一直在与Microsoft技术支持部门联系。 问题在于,由于注册表和目录已更改,无法在Windows 2008 64位上正确导出来自COM +应用程序的任何32位ServicedComponent。 这也是Windows server 2003上的一个问题,但是被修补程序修复,并且在Windows server 2008 64位中被标记为已修复,但实际上在2008年没有修复。这也是Windows 7中的一个错误。

所有关心此问题的Windows 7开发人员都应该联系Microsoft技术支持部门,告知他们正在经历这个问题,因为微软无意从客户的角度解决这个问题。 我们正在试图让MS接受我们的商业案例作为理由。 如果有任何改变,我将在未来更新这篇文章。