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

使用Windows 2003 Server或2000，生成用于其他系统的COM +应用程序代理，包括导出期间创build的MSI包中的.NET Enterprise Services组件。 .NET组件也在GAC中注册，regsvcs在安装应用程序代理期间自动运行。

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

任何人都知道该怎么做，以确保行为在2000 – 2003年那样工作？

更新我们可以使用.NET程序集生成一个代理，并且工作正常，但是如果我们尝试将其他程序集或传统VB6 COM + dll添加到同一个包中，则表示它们是为不同的处理器构build的。

为什么不同的计算机或操作系统上的文化date格式不同？

Powershell ScriptBlock不执行

钩closures应用程序

事件查看器中的行号

在.NET中自动缩放图像

更新我明白，如果你build立任何cpu模式（所有项目都设置为），那么当你通过将你的程序集放到组件服务应用程序来注册时，如果它是现有的64位应用程序，它将使用64位。 但是，这是一个32位应用程序。 有COM6应用程序中注册的VB6 DLL，它们是32位的。 所以应该使用32位registry等，并使应用程序是32位。 所以当一个.NET的任何cpu程序集添加后，它应该是32位…但是，当我们导出应用程序的.NET程序集不会被添加到.MSI创build。

更新我们发现http://support.microsoft.com/kb/924729其中讨论了32位ServicedComponents无法导出的错误…有一个修补程序，但它是用于Windows Server 2003.我们已经缩小了问题而且只有32位的ServicedComponents没有正确导出。

debugging崩溃而不会引发AppDomain.UnhandledException的exe文件

处理多个表单之间的数据

提前C＃string比较

DateTime.UtcNow.Ticks有时跳跃了一个显着的数额

将数据传递给自定义Windows服务

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

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

伯爵

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

所有关心此问题的Windows 7开发人员都应该联系Microsoft技术支持部门，告知他们正在经历这个问题，因为微软无意从客户的角度解决这个问题。 我们正在试图让MS接受我们的商业案例作为理由。 如果有任何改变，我将在未来更新这篇文章。