MTS, COM, COM+, VB FAQ

Welcome to Sabbasoft


1)		What are Serviced Components ?
2)		Do I need to resort to COM+ to use functionalities like distributed transaction management or object pooling ?
3)		How do I associate COM+ settings to my .NET class and assembly?
4)		How do I register a .NET component into the COM+ catalog?
5)		Do I need to register my .NET Serviced component into the GAC?
6)		Do I need to strongly sign a Serviced Component ?
7)		How do I implement correctly Object Pooling in the .NET framework ?
8)		Where can I find other info on Enterprise Services ?
9)		How many number of concurrent serviced components instances can run in a COM+ application ?
10)		Can I mix Serviced components and Remoting ?
11)		Can I use Application configuration files when hosting Serviced components in Server COM+ Applications?
12)		Why my .NET Serviced component ball is not spinning in the COM+ Explorer ?
13)		My client is trying to resolve server side assemblies referenced by the Serviced Component I?' accessing. How is that ?

	1) What are Serviced Components ?
	Serviced Components is the term that Microsoft has decided to use to identify .NET classes that use COM+ Services. sometime the term Enteprise services is also used to identify the use of COM+ within the .NET framework.

2) Do I need to resort to COM+ to use functionalities like distributed transaction management or object pooling ?

Yes, the .NET runtime doesn't support natively the equivalent of COM+ services. They will be probably released in a future (looks like that the code name for such project is Indigo).
Fortunately, at present, the .NET runtime provide a mechanism to let .NET managed code to make COM+ services avaialbale to .NET code.
To hook into COM+ services a .NET class must derive from System.EnterpriseServices.

3) How do I associate COM+ settings to my .NET class and assembly ?

The .NET framework lets you declare COM+ related settings for a .NET class via the standard .NET attribute based approach. This approach is something that has been long awaited for COM components but was never made available before.
Almost all the COM+ related settings available via the Component Services management console snap-in (or the COM+ catalog administration component) can be configured tagging with proper attributes assemblies, classes and methods. Only a few properties like the process identity of a server package can't be must be declared in a latter phase when the .NET component has been registered into the COM+ catalog. This is quite reasonable since you do not want to hardcode the username password into the code (as you may known, .NET IL is quite easy to reverse engineer).

Here is a sample code. MyClass requires object pooling, and MyMethod is declared as autocomplete (SetComplete is implicitly called unless an exception is thrown)

<JustInTimeActivation, _
ObjectPooling(MinPoolSize=5, MaxPoolSize=5, Enabled=true)> _
Public class MYclass

<AutoComplete()> _
Public Function MyMethod

4) How do i register a .NET component into the COM+ catalog ?

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 syntax is:

Regsvcs C:\myassembly.dll

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.

5) Do I need to register my .NET Serviced component into the GAC ?

It depends. The point to rememeber is that .NET binding policies applyes to Serviced components as well. Having the assembly registered in a COM+ application is not what a com developer tends to think. From a COM+ perspective all registered serviced components are implemented in mscoree.dll

If the component is declared to reside in a lIbrary COM+ application then it will be loaded into the client process. If the assembly is not registered into the GAC, the assembly must be placed in a directory where the CLR, applying local probing can locate it. This works exactly as any "standard" .NET assembly.

If the component is declared to reside in a Server COM+ application, the there are two processes that must be able to locate the assembly:
- The client process to bind to the assembly types
- The dllhost.exe process to load the assembly in order to execute it

Regarding the client the same as for the library COM+ applications applies.
What about the dllhost process ? it comes out that during the registration phase regsvcs add the a CodeBase entry into the registry under the InProcServer (that's under the Component CLSID).
As a side note: you can define an entry in an application config file to explicitly declare the location of an assembly, bypassing local probng and the GAC.
Note that the default entry that's usually used to identify the location of a COM component is "taken" by mscoree.dll; as a fact, as far as COM is concerned all serviced compoennts are implemented by this dll.
The CLR (specifically mscoree.dll) uses the codebase entry to locate the assembly. This means that, as long as the dllhost process you are not required to register the componetn into the GAC.ù

Said that, the quickest way to make sure to have the assembly succesfully loaded by both the client and the COM+ surrogate process is to register it into the GAC.

	6) Do I need to strongly sign a Serviced Component ?
	Any Serviced component must be hosted into a strongly signed assembly; to do this you must first run the sn.exe utility with the -k switch to generate a file containing the public/private key pair. You then sign the assembly with the key pair adding the following line in the assemblyinfo.vb file <assembly: AssemblyKeyFile("mykey.snk")>

7) How do I implement correctly Object Pooling in the .NET framework?

You've basically 2 options:

- Require Just in Time Activation and declare each method as autocomplete, or call SetComplete/SetAbort/ DEactivateOnReturn. In this way the CLR has all the info to automagically return the object to the pool.
- Have the client call dispose when done

Note that there are at present (VS 1, SP!) some problems when the object is invoked via .NET Remoting.

- Calling Dispose on the object on the client side (the transparent proxy actually) has no effect, you have to resort to the first option mentioned above.
- In case the object is declared into a Library application it is not not returned into the pool.

	8) Where can I find other info on Enteprise Services ?
	Understanding Enterprise Services in .NET Enterprise Services FAQ from GOTDOTNET

9) How many number of concurrent serviced components instances can run in a COM+ application ?

"old" VB6 COM+ components had to run in an STA. In a COM+ application the maximum size that the STA thread pool can reach is 10 multiplied by the number of processors. On the contrary, .NET serviced components, no matter what language you use, are marked as BOTH, that is, they run in the COM+ Application MTA (Multi Threaded Apartment). The COM+ runtime do not pose any limit on the thread pool size of the MTA apartment.
This means that there is no built-in limit on the number of concurrent serviced components instances which can run in a COM+ application. Nevertheless, it's better you monitor the context switch in a COM+ application process. If this gets too high it means that the processor spends more time in thread switching than doing any real job.

10) Can I mix Serviced components and Remoting ?

Yes you can. Serviced Components derive from MarshalByRefObject, so they can be accessed remotely using .NET Remoting instead of DCOM.
To do so deploy your serviced components in a COM+ library application (so that you get all COM+ benefits such as Object pooling or Declarative Transactions), then create an hosting process for your Serviced component to make it available remotely as you would do with any standard remotable object.

The pros are that you can develop specific application configuration files.

The cons are that there is no transaction flow across remoting calls, nor any built - in security support.

11) Can I use Application configuration files when hosting Serviced components in Server COM+ Applications ?

In W2K you can't. All Server COM+ Applications are hosted by different instances of the same executable: DLLHOST.EXE. Since .NET configuration files are based on the process name, you would end up mixing the configuration info of all the COM+ Server Applications hosted in the Server machine.
Just resort to something else (such as Construction strings).

On the contrary, in Windows Server 2003 (that is COM+ 1.5 and .NET 1.1) you can specify the path to a configuration file for each COM+ server application.

	12) Why my .NET Serviced component ball is not spinning in the COM+ Explorer ?
	You just need to add the EventTrackingEnabled attribute to the class. [EventTrackingEnabled(true)] class myclass { ... }

13) My client is trying to resolve server side assemblies referenced by the Serviced Component I'm accessing. How is that ?

In a classic layered application, you have the Business Layer and the Data Layer residing on the server side . Fat clients (windows form based) interact with the remote Business Layer which must then be accessible remotely.
One option to do that in .NET is to define the Business Objects as ServicedComponents, deploy them in Server COM+ Application and then produce a proxy export from the COM+ Application. The Proxy Export is just an MSI file which, when run on the client machine, copies all required assemblies and set the appropriate registry entries to let the client create and invoke methods on the the remote object.

The assemblies containing the Business objects must be present on the client machine because the CLR on the client side need to resolve the definition of the type of the remote object. There is nothing such .NET Remoting SAO which can allow you not to deploy the server assembly on the client.

As I said, in a tipical distributed architecture, Business Objects call into Data Access Components. Such objects are not ment to be called directly by the client and, since the client is unaware of them, there is no reason why they should be deploied on the client as well.

I'm pretty sure you agree with me, but unfortunately the CLR does not :( .. if you call Serviced Component B in Assembly B1, which in turns calls class D in Assembly D1 then you have to deploy Assembly D1 on the client side, if you fail to do so, the CLR on the client side will complain about the fact that it can't find Assembly D1 ?!
Note that this happens even if you make sure that
1) no types of Assembly D1 are exposed through public methods of classes in Assembly B1
2) no Assembly D1 types are used in Assembly B1 classes static constructor

(if it was the case then this behaviour would make sense).

I cannot provide a reason why. This must be well deep inside the Enterprise Services Runtime. Using Reflector I've seen that there is some code in the ServicedComponent's static and instance constructor, still I've also noticed that the Assembly D1 is not loaded when the class in Assembly B1 is newed, but when the method using the class in Assembly D1 is called; thus this must have something to do with JIT compilation.

However it is, this fact poses some deployment problems (to say the least) when deploying .NET components in a COM+ Server Application. I strongly suggest you to use an alternative approach : deploy your .NET components in a library application and make them available remotely using .NET Remoting. As a fact, this odd beahviour doesn't shown up in this case.

Comments, suggestions .. whatever .. drop me a line if you wish

You are visitor number

Since 2001/01/01