What's the purpose of COM+ library applications?

Question

When a COM+ application is created the wizard offers to choose between a library and a server application.

A server application is activated in a separate process and this can be used to cheaply interop 64-bit consumers with 32-bit in-proc COM components.

What's the use of library applications that are activated right in the caller process? Why use them instead of plain old in-proc COM servers?

Answer 1

There are several:

1. Performance - it is a bit faster as you don't have to go through the message automation (marshalling and unmarshalling)

2. Isolation - if many different Applications are using the Library, then each will have it's own copy. This point is most important when dealing with the differences between an MTA (Multi Threaded Apartment) and a STA (Single Threaded Apartment Model)

THE IN-PROC Server (which is really an out of processes, out of the caller's process) is shared by all different callers (this is a great way to have cheap IPC/RPC)

Ok I am editing with a few more definitions, and a bit more references:

1. Context is really all the state around the use of an object.
2. causality is really a thread like concept indicating the use of an object in a context. ("A causality is a distributed chain of COM method calls that spans any number of contexts in any number of processes" - from ISBN: 0-201-61594-0)

Those to concepts are discussed in about 30 pages of chapter 2 from Tim Ewald's excellent book "Transactional COM+" ISBN: 0-201-61594-0

So taking a direct quote from the summary of chapter 2: "An object can interact with its context using object context and with a given causality using call context. These two objects provide interfaces for interacting with COM+ runtime services. This style of coding, 'reaching into context' makes COM+ development very different from classic COM development."

Finally, Chapter 2 has a discussion "Why Library Applications?", (which is different from your question, Why not just plain old COM?) His arguments mainly indicate the same reasons from using a COM object, 1. Each application has it's own instance. 2. Load into non- DLLhost.exe process. 3. Much Less Overhead. 4. Simple Deploy of common Objects.

So the bottom line is that if you are not Distributed, and Not Transactional In Nature, there may be no real advantage to using COM+ over COM. But if you write a COM+ application and deploy it as a LIBRARY application, it will behave a little bit more like a COM component.

Hope that helps.

Answer 2

The main purpose is to benefit from COM+ application contexts .

CoGetObjectContext for IObjectContext or IObjectContextActivity will return E_NOTINTERFACE from pure in-process component, while it will successfully work in a COM+ library application (and a server application of course).

The security context is also available through CoGetCallContext for ISecurityCallContext .

It has nothing to do with performance or isolation.

As a site note, one way to check what's available to COM+ library applications is to run dcomcnfg.exe navigate to Component Services, Computers, My Computer, COM+ application, create a new library application and check what's still enabled (as opposed to a server application).