Assembly containing serviced classes must
go through a registration process to insert the required info into the COM+
catalog and in the registry in order to make them visible to the COM+ runtime.
Assemblies are registered using the Regsvcs.exe utility whose basic command line
In order to provide XCOPY deployment
features for serviced components, Microsoft has tried to automate this
operation: while binding to a serviced component, the .NET runtime registers the
assembly transparently if the registration info can’t be found. Unfortunately
this process, that requires Administrator rights, is run under the identity of
the caller; hence it will likely fail in a real world scenario.
It’s very important to stress the fact
that a .NET serviced component still run into the .NET runtime environment; all
such settings just declare the properties of the its associated COM+ context
that will run into the unmanaged world. The picture below gives you a clue of
the binding process to a serviced .NET component.
As you can see any creation of a serviced
component implies a call into the unmanaged world (CoCreateInstance). All such
calls are dispatched to the mscoree.dll since all serviced components are
implemented into this dll, as far as COM+ is concerned.
Having setup the proper context,
mscoree.dll calls into the managed world to create the class and pass it back
the obtained proxy to the .NET caller.
This is the VB6 pseudo-code the
mscorlib.dll uses to create the managed object while running into the unmanaged
Dim crs As New mscoree.CorRuntimeHost
Dim domain As AppDomain
Dim objh As ObjectHandle
Set objh = domain.CreateInstanceFrom("c:\myassembly.dll", "vblibrary.Class1")
Dim obj As Object
Set obj = objh.Unwrap
Once you’ve registered the assembly
containing the serviced class, a local .NET client can bind to it as if it was
dealing with a standard .NET assembly. In case a serviced class holds expensive
resources, you can explicitly release it, instead of relying on the Garbage
collector, calling the DisposeObject method that’s inherited from the
ServicedComponent class (calling the Dispose method would sort the same effect
but requiring an additional context switch).
If you mark your class with the [JustInTimeActivation]
attribute you can avoid having the client calling DisposeObject: the .NET
runtime automatically release the object when, within a method call, ContextUtil.SetComplete/SetAbort
is called (or the method is marked as [AutoComplete])
The same apply when dealing with pooled
object: If JITA is used, the object is returned to the pool when the done bit is
set to true (Setcomplete/Setabort is called or the method is marked as [AutoComplete]);
if it’s not the case you must call DisposeObject explicitly, if you fail to do
so, the object is not returned to the pool.
It’s likely that, in most scenarios, a
serviced component must be invoked remotely. You have two options to do so:
resort to .NET remoting or DCOM.
No special steps are required to invoke
the object via .NET remoting: you set up a listening process, declare your
preferences in the protocol and formatter to be used and you’re done. There
are just a couple of bugs of beta2 you’ve to be aware:
- You cannot invoke a serviced component
via .NET remoting if the component is deployed in a server COM+ application
- Calling DisposeObject on the object
wrapper hold by the client has no effect:
you must resort to JITA if you want the object to be deterministically
released (or returned to the pool)
Invoking the serviced component via DCOM
implies referencing it as if it was a COM component (thus involving .NET
interop). You can do this provided you’ve run the COM+ application proxy on
the client machine. Unfortunately there is another beta2 bug that prevents you
from doing this on Windows 2000, still the process works on Windows XP beta2.
One last consideration: know that
transaction flow cannot propagate across .NET remoting calls, consider this fact
when you must choose which remoting mechanism adopt.
It’s pretty likely that .NET will
provide built-in enterprise services in the future; still, for the while,
Microsoft has resorted completely to the good old COM+ framework to provide such
services. Provided that the bugs that affect the b2 build will be removed in the
V1 release, everyone will certainly appreciate the attribute-oriented approach
exposed by the .NET framework