1

使用 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。我们已经缩小了问题的范围down 并且只有 32 位 ServicedComponents 没有正确导出。

4

3 回答 3

3

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

伯爵

于 2010-11-10T02:04:00.203 回答
2

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

于 2012-02-07T16:17:11.493 回答
1

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

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

于 2010-01-28T16:07:42.703 回答