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

使用Windows 2003 Server或2000，生成用于其他系统的COM +应用程序代理包括MSI中的.NET Enterprise Services组件在出口期间创建的包。 .NET组件也在GAC中注册，并且regsvcs在安装应用程序代理期间自动运行。无法使用Windows 7或Windows Server 2008从COM +目录导出32位ServicedComponent 64位

但是，我们发现Windows Server 2008不包含程序集。它将包含.tlb，但不包含.dll，也不会将其安装到GAC中，当应用程序找不到组件时，一切都会炸毁。

任何人都知道该怎么做才能确保其行为与2000-2003年一样？

UPDATE我们可以生成只用.NET程序集代理，它工作正常，但如果我们尝试其它组件或传统VB6 COM + DLL文件添加到它说，他们建造了一个不同的处理器相同的封装。

UPDATE我明白，如果你在任何CPU模式（所有项目都设置为）建立，那么当你通过删除您的组件到组件服务应用程序注册，它将使用64位，如果它是一个现有的64位应用程序。但是，这是一个32位应用程序。在COM +应用程序中注册了VB6 dll，它们是32位的。所以应该使用32位注册表等，并使应用程序为32位。所以，当.NET Any CPU组件被添加后，它应该是32位的......但是当我们导出应用程序时，.NET程序集不会被添加到创建的.MSI中。

UPDATE我们发现http://support.microsoft.com/kb/924729，其中讨论了其中的32位的ServicedComponents无法导出一个bug ...有一个修补程序，但它是Windows Server 2003中我们已经收窄的问题，这只是32位服务组件没有正确导出。

来源

2009-12-18 Richard Hein

是您的Server 2008 x64吗？ – 2009-12-23 17:44:28

是的。我已经用更多信息更新了我的问题。 – 2009-12-23 18:27:36

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

来源

2012-02-07 16:17:11 Amin

感谢您的更新。不幸的是，这个项目太晚了。 :) – 2012-04-18 14:46:59

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

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

来源

2010-01-28 16:07:42

微软表示它不会解决这个问题。 – 2010-03-05 17:43:37

那么分辨率是多少？我试图导出到一个32位机器一个COM +导出生成在2008 R2 64位，它不工作。我可以自己创建细节吗？ – 2012-01-04 08:53:28

@JonH正如我所说，微软不会解决这个问题。没有解决方案，所以你必须找到另一种方式。 – 2012-01-04 14:29:01

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

伯爵

来源

2010-11-10 02:04:00 Earl

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

回答

相关问题