无法使用Windows7或Windows 2008 64位从ServicedComponent目录导出32位COM+

Question

使用Windows2003Server或2000生成在另一个系统上使用的COM+应用程序代理，它在导出期间创建的.NET企业服务包中包含.NET企业服务组件。.NET组件也在GAC中注册，并且regsvcs在安装应用程序代理期间自动运行。

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

有谁知道如何确保这种行为像2000-2003年那样起作用？

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

UPDATE I理解，如果您构建在任何CPU模式下(所有项目都被设置为该模式)，那么当您通过将程序集放到组件服务应用程序中注册时，如果它是现有的64位应用程序，它将使用64位。然而，这是一个32位的应用程序.有一些在VB6应用程序中注册的COM+ dll，它们是32位。因此，应该使用32位注册表等.，并使应用程序为32位。因此，当一个.NET任何CPU程序集后添加，它应该是32位.然而，当我们导出应用程序时，.NET程序集不会被添加到创建的.MSI中。

UPDATE我们找到了http://support.microsoft.com/kb/924729，它讨论了一个32位ServicedComponents无法导出的错误.有一个修补程序，但它适用于Windows 2003。我们已经缩小了问题范围，只有32位的ServicedComponents没有正确地导出。

Answer 1

MS已经修复了2008年度的这一问题。我们能够让他们确认它是一个bug，并在去年发布了一个修补程序。试着联系他们得到高频信号。

Answer 2

编译到任何cpu的.NET dll在被jit编译时都会具有比特性。COM+只有一种痛苦的感觉。x86或x64，但不是中性的。因此，您需要使用这两个CPU中的一个，而不是任何CPU。

伯爵

Answer 3

我已经与微软的技术支持部门取得了联系。问题是，由于注册表和目录的变化，无法在Windows200864位上正确地从COM+应用程序导出任何32位的COM+。这在Windows 2003上也是一个问题，但是由一个修补程序修复，并且在Windows 2008 64位中被标记为固定，但实际上在2008年没有修复。这也是Windows 7中的一个bug。

所有关心此问题的Windows 7开发人员都应与Microsoft技术支持部门联系，以报告他们正在经历此问题，因为如果没有客户的成本证明，Microsoft不打算修复此问题。我们正在努力让MS接受我们的业务案例作为理由。如果有任何变化，我会在将来更新这个帖子。