Running managed .Net COM+ services side-by-side in IIS6.0

Question

We have a managed .Net COM+ component which inherits from ServicedComponent and are trying to use this as a side-by-side assembly from a web application in IIS 6.0 on Windows Server 2003.

We have generated an assembly manifest using mt.exe and have successfully run this in side-by-side mode in a test console application. However, when it comes to IIS it just doesn't seem to work and rather than reading the manifest goes off the registry to attempt to find the COM+ application there.

The manifest is generated using mt.exe -managedassemblyname:myassembly.dll -out:myassembly.manifest which is then copied to the virtual directory of the web application. Using filemon reveals that the manifest is never even read!

Moving the .manifest file to the bin directory it then seems to be read but the same issue occurs.

Help from anyone who has successfully got this working would be greatly appreciated.

Answer 1

External manifests ending in ".manifest" are only automatically picked up for executables. So you have to tell IIS or Windows about your manifest, or no one's going to bother to read it.

Presumably in your console application testing, either the executable's manifest has a reference to MyAssembly or contained the relevant information directly.

Now, I'm not greatly familiar with ServicedComponent here, so I'm going to talk in general terms.

1. If you get to control all of the software that calls into MyAssembly, you can deliberately load up the information in the manifest first, activate that information onto the thread, call into MyAssembly, and deactivate. This is the best way to satisfy this kind of plugin architecture, because you're not polluting the parent process, you're only configuring the thread your code is running on for the duration your code is running. This approach is done through invocation of the activation context APIs, of which you can find some great examples in the reg-free COM samples bundled with the All-in One Code Framework
2. If you don't get to control all the code calling into MyAssembly (if it's being called automatically by IIS) or if it's being called in too many places and the approach suggested above is too costly, you could always try a "hackaround" here. Take the IIS6.0 worker process executable, and edit its manifest if it has one, or add a new manifest if not (don't forget to check if it has an embedded manifest), to have a dependency on MyAssembly. In this approach, MyAssembly's manifest content essentially becomes part of the running context for any code running inside IIS6, so it's a pretty heavyweight approach.