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

Question

使用 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 无法正确导出。

Answer 1

编译到任何 cpu 的 .NET dll 在 jit 编译时都会有一点点。 COM+只有硬位感。 x86 或 x64，但不是中性的。因此，您需要使用两者之一，而不是任何 CPU。

伯爵

Answer 2

MS 为 2008r2 提供了针对此问题的修补程序。我们能够让他们确认这是一个错误并在去年发布了一个修补程序。尝试联系他们以获取 HF。

Answer 3

我已就此与 Microsoft 技术支持联系。问题是您无法在 Windows 2008 64 位上正确地从 COM+ 应用程序导出任何 32 位 ServicedComponent，因为注册表和目录的方式已更改。这也是 Windows Server 2003 上的问题，但已通过修补程序修复，并在 Windows Server 2008 64 位中标记为已修复，但实际上在 2008 年未修复。这也是 Windows 7 中的错误。

所有关心此问题的 Windows 7 开发人员应联系 Microsoft 技术支持报告他们遇到此问题，因为 Microsoft 无意在没有客户提供成本证明的情况下解决此问题。我们正在努力让 MS 接受我们的商业案例作为理由。如果有任何变化，我会在以后更新这篇文章。