Custom Surrogate. Well, the use of CoRegisterSurrogateEx() turned out to be easier than I expected. I buildt a small managed sample to... [Commonality]
A few comments on using CoRegisterSurrogateEx.
CoRegisterSurrogateEx expects the application id of an Enterprise Services/COM+ package. It "consumes" the calling thread and sets up the COM+ thread pools, etc. on top of the calling host.
Using CoRegisterSurrogateEx causes your server apps to behave the exact same way as if they were hosted by dllhost.exe. Dllhost.exe is a very thin wrapper around this exact API. If you launching the app from within managed code (as Tomas does it), the activated serviced components will be activated in the default domain of the host and free them from the "GAC ghetto".
Bad news: COM+ will ALWAYS start packages on top of dllhost.exe if an activation occurs and the package isn't running. That means that your custom host must be running before any activation takes place. The best ways to guarantee this are only available on COM+ 1.5:
(a) Disable/Enable the application when your own host spins up and shuts down. That requires that the custom host runs in the context of a principal with write access to the COM+ catalog.
(b) Host the application inside a managed Windows Service, register the COM+ app to "run as NT service" and patch the registry (yes, you heard right) for that service so that the service host is your own host and not dllhost.exe. The registry value to patch is under "SYSTEM\\CurrentControlSet\\Services\\{ServiceName}" and there the ImagePath" value. That must be set to your exe instead of dllhost.exe. The service must be set up to match the logon identity of the COM+ app. It can't be "interactive user", obviously.
If you grab my esutilities and try the EnterpriseServicesApplicationInstaller setting its "UseCustomSurrogateService" property to true, it'll dump a service process exe right next to the registered assembly and do the necessary registry patches. (Source code for some of these things isn't available but will be available in the forseeable future.)
On Windows 2000, you will probably have to register/unregister the whole COM+ app at startup/spindown as Disable/Enable isn't available there. Due to the auto-registration features of Enterprise Services that isn't really as bad as it sounds -- it's still bad, but not SO bad.
