Binaryworld - Reduce COM+ context overhead: activate in the caller's context ... [ VB.net -> COM+ ]

Even though you may want to use some COM+ services, it doesn't mean that you have to have a unique context for each and every instance. The root instance, that is, the instance that the client uses, must have a context, but the secondary instances can often co-locate within the first context.

In Component Services Explorer there is a checkbox called "Must be activated in the callers context" that you can check for secondary components. It won't force your instances to be co-located, but you will get an error message, when they can't be.

By the way, in .NET, you can decorate the class with an attribute to get the checkbox selected. In Visual Basic. NET it looks like this:

Public Class MyServicedComponent
Inherits ServicedComponent

For a component to have its instances co-located, the following must be true:
The COM+ application may not use component level security
The component may not use JIT activation
The component may not use COM+ transactions.
The component may not use events and statistics.
The component may not use synchronization.
The word 'use' above is a bit misleading. What I mean is that those services should be disabled. Since the instances will be co-located in another context and that context might use COM+ transactions, then the secondary instances will participate in the same transactions. In COM+ 1.5, Component Services Explorer helps you to avoid using incompatible settings. If you enable "Must be activated in the callers context", the necessary changes will be made.