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.
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.
Anyone know what to do to ensure the behaviour works as it does in 2000-2003?
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.
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.
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.
Best Answer
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.