 |
Dienstag, 26. November 2002 |
|
I start to wonder whether it may make sense to do a conference or tour really dedicated to Enterprise Services in XP/.NET Server. 5:16:35 PM  comments []
|
|
CoRegisterSurrogateEx continued: Tomas comments here in the blog: "Let me see if I get one thing straight: You say we should _enable_ the application when the host starts up and _disable_ it when it shuts down, right?" --- Yes, exactly. "While we're on it, I think in many cases it would just be enough (and easier, up to a point), to simply make the application components fail activation if they're not running inside your custom surrogate.... what do you think?" -- That would be a good safeguard to avoid failures causes by an incorrect "activation environment". Still, throwing exceptions at activation time is a good indicator that something is wrong, but it won't help you spinning up a working host. Also, once a "wong host" is running, you'll have problems getting the custom host to run properly. Therefore, disabling or "run as NT services" is the better idea Summary: You can host COM+ server applications in a custom host process, with all features. In fact, the host process doesn't need to be fully dedicated to hosting the COM+ app. You just need to spin up one thread for CoRegisterSurrogateEx (which in turn will spawn all thread required for the COM+ app), while other threads can do other things. 4:53:18 PM comments []
|
|
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.
10:50:52 AM comments []
|
