使用 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 无法正确导出。
最佳答案
编译到任何 cpu 的 .NET dll 在进行 jit 编译时将呈现一个位数。 COM+只有硬位感。 x86 或 x64，但不是中立的。因此，您需要使用两者之一，而不是任何 CPU。
厄尔
关于.net - 无法使用 Windows 7 或 Windows Server 2008 64 位从 COM+ 目录导出 32 位 ServicedComponent，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1930215/