从COM +目录使用的是Windows 7或Windows Server 2008 64位无法导出一个32位的ServicedComponent [英] Cannot export a 32-bit ServicedComponent from COM+ Catalog using Windows 7 or Windows Server 2008 64-bit

问题描述

使用Windows 2003 Server或2000，生成用于在其他系统上使用COM +应用程序代理，包括导出过程中创建的MSI软件包内.NET企业服务组件。在.NET组件也注册在GAC和regsvcs安装应用程序代理时会自动运行。

Using Windows 2003 Server or 2000, generating a COM+ application proxy for use on another system, includes .NET Enterprise Services components within the MSI package created during export. The .NET components are also registered in the GAC and regsvcs runs automatically during installation of the application proxy.

然而，我们发现，Windows Server 2008中不包括的组件。这将包括.TLB而不是.dll文件，也没有在GAC中安装它，当然一切都炸毁当应用程序无法找到程序集。

However, we have discovered that Windows Server 2008 does not include the assembly. It will include the .tlb but not the .dll, nor install it in the GAC, and of course everything blows up when the application cannot find the assembly.

任何人都知道该怎么做，以确保行为的工作，因为它在2000 - 2003年？

Anyone know what to do to ensure the behaviour works as it does in 2000-2003?

更新我们可以生成只用.NET程序集代理，它工作正常，但如果我们试着给其他组件或传统VB6 COM +的dll添加到同一个包，它说，他们建对于不同的处理器。

UPDATE We can generate a proxy with just the .NET assembly, and it works fine, but if we try to add other assemblies or legacy VB6 COM+ dlls to the same package it says they were built for a different processor.

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

UPDATE I understand that if you build in Any CPU mode (which all projects are set to), then when you register by dropping your assemblies into the Component Services application, it will use 64 bit if it's an existing 64-bit application. However, this is a 32-bit application. There are VB6 dlls that are registered in the COM+ application, which are 32-bit. So that should use the 32-bit registry etc..., and cause the application to be 32-bit. So when a .NET Any CPU assembly is added after, it should be 32-bit ... however when we export the application the .NET assembly doesn't get added to the .MSI which is created.

更新我们发现 http://support.microsoft.com/kb / 924729 其中讨论，其中32位的ServicedComponents不能导出的错误...有一个修补程序，但它是Windows Server 2003中，我们已经缩小了问题下来，这是只有32位的ServicedComponents是不出口正常。

UPDATE We have found http://support.microsoft.com/kb/924729 which discusses a bug where 32-bit ServicedComponents cannot be exported ... there is a hotfix, but it is for Windows Server 2003. We have narrowed the problem down and it's only 32-bit ServicedComponents that are not exporting properly.

推荐答案

MS具有修复此问题的2008R2。我们能够让他们将其确定为一个bug，发布的修补程序的最后一年。尝试联系他们，以获得HF。

MS has hotfix for this issue for 2008r2. We were able to get them to confirm it as a bug and release a hotfix last year. Try contacting them to get the HF.

这篇关于从COM +目录使用的是Windows 7或Windows Server 2008 64位无法导出一个32位的ServicedComponent的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！