|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here. ArchiveDisclaimer|
Registering Serviced Components
A serviced component is hosted by a COM+ application and must be accessible to that application. For accessibility, serviced components have the following registration and configuration requirements:
Assembly must be strong-named. For additional information, see Signing an Assembly with a Strong Name.
Assembly must be registered in the Windows registry.
Type library definitions must be registered and installed into a specific COM+ application.
Services added programmatically must be configured in the COM+ catalog.
Registration information that is useful to serviced components includes the following:
COM+ Application Identity
You can identify an existing COM+ target application by name or GUID. The .NET Services Installation Tool (Regsvcs.exe) provides the /appname: option to specify an application name.
For information on how to specify an application name, see How to: Set the Application Name by Using the ApplicationName Attribute.
For information on how to specify an application ID, see How to: Apply the ApplicationID Attribute to an Assembly.
For dynamic registration, the only way to specify a target application is by applying the ApplicationNameAttribute, ApplicationIDAttribute, or GuidAttribute attribute at design time. The .NET Services Installation tool (Regsvcs.exe) provides the /appname: switch to specify application name or GUID at compile time. Regsvcs.exe also provides the /parname: switch to identify a specific COM+ partition. The COM+ Partitions service is available only on Windows Server 2003 platforms.
If the target application is not identified or not found, the registration mechanisms create an application by using the full name of the assembly without the version number.
Do not use the ApplicationIDAttribute attribute with the COM+ Partitions service. If you are using the COM+ Partitions service, applying the ApplicationIDAttribute attribute prevents partition configuration. The COM+ Partitions service is available only on Windows Server 2003 platforms.
The activation type determines what process your serviced components are created in. You can apply the ApplicationActivationAttribute attribute to an assembly to specify the activation type. The ApplicationActivationAttribute attribute must be declared with either of the following two enumeration values:
ActivationOption.Library: Specifies a COM+ library application; serviced components in the assembly are activated in the caller's process.
ActivationOption.Server: Specifies a COM+ server application; serviced components in the assembly are activated in a new system-provided process.
For information on how to set the activation type of an application, see How to: Set the Activation Type of an Application.
If the ApplicationActivationAttribute attribute is set to ActivationOption.Server, the assembly and any assemblies on which it depends must be added to the global assembly cache (GAC) by using Windows Installer before the server application can be used; otherwise, the application generates an exception. In addition, if the ApplicationActivationAttribute attribute is set to ApplicationOption.Server, any parameters for serviced components must be marked as System.Serializable or derive from the System.MarshalByRefObject class. If not, the application generates an exception.
A description is optional but sometimes useful for distinguishing similar assemblies.
For information on how to set the activation type of an application, see How to: Apply the Discription Attribute to an Assembly.
The following topics in this section describe the registration mechanisms for deploying applications that use COM+ services:
Both registration mechanisms simplify the registration process by combining the steps required to register a serviced component. Both require that the component user be a member of the Administrator group. For dynamic registration, you can supply registration information at design time and some at compile time. For manual registration, you can supply this information at design time, compile time, and registration time. If you omit registration information, the registration process generates it from metadata. The registration process detects and sometimes corrects incompatible attribute combinations.