Registering Serviced Components

Článek
10/17/2014

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
Activation type
Description information

COM+ Application Identity

You can identify an existing COM+ target application by name or GUID. The .NET Framework Services Installation Tool (Regsvcs.exe) provides the /appname: option for specifying an application name. The following example shows how to supply the application name by using the assembly-level ApplicationName attribute.

Imports System.EnterpriseServices
<assembly: ApplicationName("BankComponent")>
Public Class Account 
Inherits ServicedComponent
   Shared Sub Main()
   End Sub
End Class 
[C#]
using System.EnterpriseServices;
[ assembly: ApplicationName("BankComponent")]
public class Account : ServicedComponent
{
   static void Main() 
{}
}

If you apply the ApplicationID attribute (or the Guid attribute) to an assembly, as in the following example, all searches for the application are based on that GUID, not on the application name.

Imports System.EnterpriseServices
<assembly: ApplicationName("BankComponent")>
< assembly: ApplicationID("4fb2d46f-efc8-4643-bcd0-6e5bfa6a174c")>
Public Class Account 
Inherits ServicedComponent
   Shared Sub Main()
   End Sub
End Class 
[C#]
using System.EnterpriseServices;
[ assembly: ApplicationName("BankComponent")]
[ assembly: ApplicationID("4fb2d46f-efc8-4643-bcd0-6e5bfa6a174c")] 
public class Account : ServicedComponent
{
   static void Main() {}
}

Note 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 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.

CAUTION 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.

Activation Type

The activation type determines whether your serviced components are created in the caller's process (library) or a new process (server). You can apply the ApplicationActivationAttribute attribute to specify the activation type.

**Note **If the ApplicationActivationAttribute attribute is set to 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 Server, any parameters for serviced components must be marked as Serializable or derive from the MarshalByRefObject class. If not, the application generates an exception.

The following example shows how to set the activation type to "server".

Imports System.EnterpriseServices
< assembly: ApplicationActivation(ActivationOption.Server)>
Public Class Account 
Inherits ServicedComponent
   Shared Sub Main()
   End Sub
End Class
[C#]
using System.EnterpriseServices;
[ assembly: ApplicationActivation(ActivationOption.Server)] 
public class Account : ServicedComponent
{
   static void Main() {}
}

Description Information

A description is optional but sometimes useful for distinguishing similar assemblies. The following example shows how to apply the DescriptionAttribute attribute to set the description on an assembly.

Imports System.EnterpriseServices
< assembly: Description("BankComponent assembly")>
Public Class Account 
Inherits ServicedComponent
   Shared Sub Main()
   End Sub
End Class
[C#]
using System.EnterpriseServices;
[ assembly: Description("BankComponent assembly")] 
public class Account : ServicedComponent
{
   static void Main() 
{}
}

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 (defined later) 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.

Sdílet prostřednictvím

Registering Serviced Components

COM+ Application Identity

Activation Type

Description Information

See Also

Další materiály