COM & .NET Component Services

COM+ Configured Components

COM+ allows you to import only in-proc (DLL) components. You cannot import COM components that reside in a local server (EXE); COM+ lets you configure the activation type of your application, server, or library. In the case of a library, the client simply loads the original DLL into its process and uses the component. If you configure the application to be a server application, COM+ promotes your original DLL to become a local server by hosting it in a surrogate process of its own. However, COM+ cannot make a library application out of a COM local server. In addition, many COM+ services require explicit process-level administration that the local server’s code simply does not contain.

Once an in-proc component is imported to COM+, it is called a configured component to emphasize the fact that much component functionality and behavior is actually configured and administered outside the component. A classic COM component (be it in-proc or local) that has not been imported into COM+ is called a nonconfigured component. Configured and nonconfigured components can interact freely and call each other’s interfaces. The configured component must reside on a Windows 2000 machine, but the client of a configured component can reside on any Windows-family machine, such as Windows NT, Windows Me, or Windows 9x.

Configuration lets you control the way your application, component, interface, or method behaves under COM+. The COM+ development paradigm lets COM+ manage as much of the nonbusiness logic plumbing as possible by declaring what services you want to use. Doing so lets you focus on the domain problem you are trying to solve and add business value instead of plumbing code to your product.

Your configured component’s interfaces can be dual, dispatch, or custom interfaces. If you use automation-compliant interfaces, you do not need to provide COM+ with a proxy/stub DLL (see COM Interface Types for more information).

COM Interface Types

In general, there are two kinds of COM interface types: automation-compliant interfaces and custom interfaces. Contrary to common conceptions, an automation-compliant interface does not have to derive from IDispatch or have all the parameters be variants or variants-compatible types (such as a BSTR or long). An automation-compliant interface must have one of the following two directives in its definition: dual or oleautomation. For example:

[
   object,
	 uuid(30548235-4EC3-4087-9956-ED26748F47E9),
	 dual,
	 helpstring("An example for automation compliant interface"),
]
interface IMyInterface : IUnknown
{
   HRESULT MyMethod([in]long lNumber);
};

COM can marshal an automation-compliant interface by creating the appropriate proxy and stub automatically at runtime. However, automation-compliant interfaces do have limitations on parameter types; for example, they cannot have as method parameters structs with pointers in them. For ultimate flexibility, you can use custom interfaces. These interfaces do not have dual or oleautomation in their interface definition, and it is the developer’s responsibility to provide a proxy and a stub DLL.

However, if your design calls for custom interfaces, you should provide COM+ with a proxy/stub DLL that was built using the MIDL switch /Oicf to enable type library marshaling. In any case, configured components cannot use interfaces that require custom marshaling. You can develop configured components in C++, Visual Basic, or even C#, since one of the core principles of COM, language independence, is maintained in COM+.

You may be wondering by now, where does COM+ store the configuration information for all your applications and components? Unlike classic COM, COM+ does not use the Windows registry. COM+ uses a dedicated repository called the COM+ catalog. No formal Microsoft documentation of the exact physical location of the catalog exists, simply because it is not useful to you. The only bit of configuration information still stored in the Windows registry is the component threading model and remaining classic COM information (such as InprocServer32 and prog-ID registry keys).