In Chapter 1, you learned that there’s a place for COM in your .NET application development toolbox. Likewise, there’s a place for COM+ when you’re working with .NET. Although COM+ doesn’t have as long a history as COM, it’s based on COM technology and provides added value that developers still need, even if they’re using .NET for most of their development tasks.
In many respects, this chapter continues the story begun in Chapter 1. It takes the next logical step of addressing the need for COM+ in .NET application development tasks. This chapter is an overview—we’ll cover most of the issues in this chapter in much greater depth as the book progresses. You’ll also learn about two valuable Microsoft Management Console (MMC) snap-ins in this chapter. The value of these tools becomes apparent in later chapters, when you learn how to perform application tasks such as installing a COM+ application.
Note
MMC is a container application that holds special COM components known as snap-ins. Most snap-ins provide some type of administrative aid, but a developer could create a snap-in to serve just about any purpose. A preconfigured setup that includes one or more snap-ins is called a console. You’ll find a number of consoles in the Administrative Tools folder of the Control Panel. The two consoles discussed in this chapter help you configure the COM+ Component Services and the .NET Framework.
Many developers have gotten the idea that .NET is all about Web services and distributed applications that rely on the Internet. In reality, .NET supports this type of development in addition to all other past forms of development. In some cases, using Web services for distributed application development isn’t the correct strategy because a company might have a large investment in existing technology or might need the additional security or performance that COM+ can provide. Consequently, COM+ plays an important role in distributed application development.
In many cases, .NET developers will still need the transactional or message-based application support provided by COM+. These two applications are specific examples of the continued need for COM+ use with .NET—at least for the present.
Database applications that run only on an internal LAN or WAN and need the highest level of reliability make use of the transactional support provided by COM+. A transaction tracks the data as it moves from client to server. Only completed transactions actually appear in the database. Failed transactions are rolled back so that the database remains in a stable state without data corruption.
By using asynchronous data processing, message-based applications eliminate the requirement for sender and receiver to exist at the same time. A recorder creates the message based on data the sender wants to send to the receiver. (In most cases, the client will send data and the server will receive it, but the server can also send data to the client.) Microsoft Message Queuing Services (MSMQ) manages the message queue used to hold the message until the recipient can process it. The message queue can appear on the local machine—the remote machine always has a queue to store incoming messages. When a message arrives in the remote queue, a listener alerts the COM+ component to the change in queue status. A player interprets the message content for the component, which then processes the data sent by the sender.
MSMQ helps developers create disconnected applications for independent clients—that is, applications that store data locally until the client has a connection to the server. In short, this technology eliminates the need to use any type of connection while the user is "on the road." The server can also use queues to store messages until it has time to process them. The queue collects messages during peak periods, which the server continues processing during slow times. This technique tends to use server resources more efficiently because the application continues to operate during periods of low activity.
The final reason I discuss in this chapter for using COM+ with .NET applications is the level of security it provides. You’ll see as the chapter progresses that COM+ provides role-based security, which enables you to set access requirements based on the client’s role. For example, you can set security separately for managers and employees. COM+ also allows you to set security at various levels: component, interface, and method. This level of security support is more granular than that which COM provides and overcomes some configuration difficulties developers experienced with COM applications in the past.
Chapter 1 pointed out a number of issues the developer must face when working with COM. You also learned about DCOM issues and how they affect the distributed programming environment. COM+ relies on both of these technologies, so it shouldn’t be too surprising to learn you’ll run into the same problems working with COM+ that you do working with either COM or DCOM. For example, making COM+ applications work across an Internet connection through a firewall is just as hard a task as it is with DCOM applications.
COM+ also includes a few problems of its own. As with COM and DCOM, many developers find COM+ daunting to learn. However, COM+ increases the learning curve by adding more functionality. You not only have COM and DCOM issues to worry about, you also have additional concerns such as how to use certain features. Many developers still don’t understand how the publish/subscribe model works, and others find role-based security a long leap from COM and DCOM security options.
Another problem is that COM+ tends to change the rules. For example, when working with COM or DCOM, a developer was encouraged to allocate a resource and then hold onto it until every possible need was met. COM+ changes this rule by insisting the developer allocate a resource, use it as quickly as possible for the task at hand, and then release it. In sum, there’s a contradiction in the way that COM and COM+ handle the same issue. This problem causes confusion in the developer community—more confusion than even COM and DCOM created.
Note that Microsoft recognized some deficiencies in the COM and DCOM approach when they were creating the COM+ technology and worked to eliminate these deficiencies. Instead of using the straight connection found in COM and DCOM, COM+ relies on interceptors (code that captures the communications stream and performs either pre- or post-processing to add functionality to the technology). For example, COM+ relies on interceptors to provide the role-based security many developers have found to be a useful alternative to the security COM provided in the past.
One of the more important improvements in COM+ is the management features it provides. You’ll learn about COM+ management in the "Using the Component Services MMC Snap-In" section that follows. The short explanation is that you don’t need to worry about the registry as much when working with COM+. Most of the administrative tasks you’ll perform occur within a GUI or when using specially created installation programs.
Using the Component Services MMC snap-in is an essential part of the development process for COM+ applications. This snap-in helps you perform the following tasks:
Install components as part of creating a COM+ application.
Export an application proxy so that the client can access the component.
Help the developer or administrator set component security based on the roles users will play in application use.
The Component Services snap-in also provides support for the COM+ publish/subscribe event model. Finally, given the right application setup, the Component Services snap-in will log significant component events for you or you can add event logging support directly into the component. In short, this is the one utility you absolutely must know about to make COM+ applications work.
The next two sections of the chapter discuss the main Component Services areas. We’ll begin by looking at the interface for those of you who are new to the MMC snap-in approach to working with administration. Once you have a basic understanding of the interface, we’ll discuss what you need to do to install COM+ components on the server. This section includes everything from creating the COM+ application to exporting a proxy for the client’s use.
The Component Services console shortcut appears in the Administrative Tools folder of the Control Panel. Starting this console displays a window similar to the one shown in Figure 2-1. Notice the console includes the Component Services, Event Viewer, and Services snap-ins. Component Services is where you’ll manage the COM+ applications you create. Event Viewer helps you to track any significant COM+ events. In most cases, you’ll use this area to view any errors the COM+ application records. Finally, Services will help you to work with the various operating system services installed on the target machine.
Figure 2-1. Component Services is the main utility that you’ll use for installing and managing COM+ components.
As with most MMC snap-ins, in the left (scope) pane Component Services uses a hierarchical display (similar to the one found in Windows Explorer) and a detailed view of the highlighted item in the right (results) pane. Most of the icons in this view have context menus you can access with a right click, just as you would with most Microsoft Windows applications. The context menus tell what tasks you can perform. In short, there isn’t anything too unusual about this interface from a usage perspective. If you know how to use Windows Explorer, you’ll have a good idea of how to use this MMC snap-in.
Both Event Viewer and Services let you view a single machine. You can choose the machine you want to view by right-clicking the appropriate folder, and then choosing Connect To Another Computer from the context menu. You’ll see the Select Computer dialog box as shown in Figure 2-2. The Browse button helps you select any available computer on the network, including servers that you have rights to access. Click OK, and Windows will connect you to the specified computer.
Component Services allows you to view more than one computer at a time. This feature helps you to move COM+ applications from one machine to another in the same way you’d move files using Windows Explorer. You can add a computer to Component Services by right-clicking the Computers folder, and clicking New and then Computer in the context menu. You’ll see an Add Computer dialog box. As with the Select Computer dialog box, you can use the Browse button to find other computers on the network.
The actual content of the Component Services snap-in can vary by operating system version. Figure 2-1 shows the four folders that Windows XP users can access:
COM+ Applications
DCOM Config
Distributed Transaction Coordinator
Running Processes
Windows 2000 users will normally see the COM+ Applications and Distributed Transaction Coordinator folders (as shown in the WinServer entry in Figure 2-3), which are the two folders we need to discuss in this chapter. Let’s begin with the COM+ Applications folder. Servers normally have more default applications than workstations do because they have more COM+ roles to fulfill. Figure 2-3 shows a comparison between the default applications for a work-station (My Computer) and for a server (WinServer). Note that Component Services uses a different icon for a local connection than it does for a remote connection so that you can easily see when you’re working with the local machine.
COM+ applications contain at least two folders: Components and Roles. A Windows XP installation adds a Legacy Components folder to the mix. Roles are a security requirement for a particular component, interface, or method. We’ll talk about roles in the "Adding Security to a COM+ Application" section later in the chapter. For now, let’s talk about the construction of COM+ applications from the component perspective.
Components contain one or more interfaces. Each interface contains one or more methods. Methods are what you’ll use to access the functionality that the COM+ application provides. You’ll often find more components within server applications because servers require more flexibility. However, each of these components will be the same whether found on a workstation or server. In other words, you won’t find one version of a component on a workstation and another version on a server—any extra functionality the server requires will appear within a separate component.
Each application level provides property settings that modify that level’s behavior. For example, you can set role-based security parameters for a COM+ application at the application, component, interface, and method levels. This means you get a very fine level of control over the behavior of an application. Not every level has the same settings because every level performs a different function within the application hierarchy. The folders directly above each application level allow you to organize that level and change the method of presentation. This includes the choices presented by the MMC snap-in as well as the application itself. In a few cases (where applicable), you’ll see a New option on the context menu for the folder that permits you to add a new item. We’ll see how this works in the "Creating COM+ Applications and Installing Components" section that follows.
Building a COM+ application doesn’t require any programming once you create the required components. However, COM+ applications don’t just appear on your server because you’ve created all the required components. You need to use a wizard to create an empty COM+ application. Once you have the application in place, you can add components to it using a different wizard. Each component is added separately; there isn’t any way to add them as a group. Windows automatically detects component details to complete the application for you. The purpose of this section is to show you how to perform these two COM+ application creation steps.
As with any component, you have to register your COM+ components. In the past, you relied on the integrated development environment (IDE) to perform the task automatically, used RegSvr32 to perform the task manually, or included the registration as part of an installation program or other form of automation. When working with .NET applications, you’ll rely on the RegAsm utility as a replacement for the RegSvr32 utility. However, the result is the same as when using unmanaged components—the component is still registered in the registry.
In the world of COM+, you don’t use any of these registration methods—Windows registers the component for you as part of the process of adding components to a COM+ application. The act of installing a component registers it on a server that it hasn’t been registered on before. We’ll see in this section that you still need to use the RegAsm utility to create a type library for the COM+ wizards to access.
I’ve created a component for demonstration purposes in this chapter. You don’t need to create the component or write any code. All the code for this section appears in the Chapter02MyMath folder of the companion content. You can download the companion content from the Web at http://www.microsoft.com/mspress/books/6426.asp. The purpose of this sample component is to help you learn how the two wizards work. Examples later in the book will show you how to create various types of components you can register using the procedures we’ll discuss here.
The following sections show how to use the Component Services MMC snap-in to register and install the MyMath component (which includes the MathFunctions class). You’ll also learn a little about COM+ security and how to export your application to install it on a client machine. The exported application acts as a proxy the client will call to access the component on the server.
The first thing we need to do is create a new application for our component. The following procedure shows you how to add a new application to Component Services. (This process is different than those you’ve used for other component types.)
Move the component to a convenient directory on the server. I normally use a central repository for my custom components, but you can use any management scheme you like, including creating special folders for each project you work with. Because of the way .NET components work, you’ll need to create a type library (TLB) file and register the component in the Global Assembly Cache (GAC) so that the common language runtime can find it.
Type RegAsm MyMath.dll /tlb:MyMath.tlb at the command prompt in the folder used to hold the component, and then press Enter. This step does register the component, but you’ll find that the registration doesn’t work as anticipated with COM+. What we need out of this step is the type library.
Type GacUtil -i MyMath.dll, and press Enter at the command prompt. This step registers the component globally so that the common language runtime can find it when needed. Now we need to register the component with COM+.
Tip
During the design and debugging phase of component construction, it pays to create batch (BAT) files that contain the registration and unregistration commands. I usually create one batch file for each purpose. You’ll find examples of these two files in the Chapter02MyMathinDebug folder of the source code.
Open the Component Services console if you haven’t done so already.
Highlight the COM+ Applications entry, and then click the Action menu and then click Application in the New submenu. You’ll see the Welcome To The COM+ Application Install Wizard dialog box.
Click Next. You’ll see the Install Or Create A New Application page. The Install Pre-built Application(s) option is specifically designed to allow you to install third-party applications. These applications come with an installation file with an MSI extension that contains all the particulars about the application. We won’t talk about pre-built applications for most of the applications in this book. Since we’re developing our own application, we’ll need to use the Create An Empty Application option.
Click the Create An Empty Application option. You’ll see the Create Empty Application page as shown in Figure 2-4. This page contains a field that holds the name for your application. It also asks you to decide between a library and server application type. In most cases, you’ll choose the Server application option because the components you create will execute in a separate process on the server. Library applications execute within the creator’s process, which means an errant component can cause the application to fail. In addition, library applications don’t support load balancing, remote access, or queued components. Library applications do, however, execute faster because there are fewer process boundaries to cross.
Type a name for the application. The example uses MyMathApp, but you can use any name you like.
Choose between the Server Application and Library Application options. The sample application uses the Server Application option because it allows more complete testing of the component and better protection during debugging.
Click Next. You’ll see the Set Application Identity page as shown in Figure 2-5. This page helps you choose the identity used to run the component. You’ll normally choose the Interactive User option because it allows you to test for role-based security using the identity of the person logged onto the server. The second option, This User, relies on the identity of a specific person. It’s handy for situations when you know another server rather than a user will use the component. Using this setting is convenient because the component will always allow the same level of access no matter who makes the request.
Choose the Interactive User option, and then click Next. The example will use the Interactive User option because it provides better application security. This setting will augment the role-based security that we’ll talk about later. You’ll see the final COM+ Application Wizard page.
Click Finish. The new application will appear in the list of applications in the COM+ Applications folder. Notice that Windows automatically creates a directory structure you can use for working with the component. We’ll use this directory structure in the steps that follow to fully configure the COM+ application for use.
The application we’ve just defined acts as a container for our component. In fact, you could place multiple components within this directory structure—the whole idea is to keep the various applications on the server separate, not necessarily to restrict how you add new components to the server. At the moment, we still don’t have the sample component (found in the Chapter02MyMathinDebug folder as MyMath.dll) installed in Component Services. The following steps will show you how to install the component, even if it isn’t registered on the current machine.
Open the MyMathApp application, and you’ll see a minimum of two folders: Components and Roles. (You must highlight the Components folder to add new components to the application.) The Components folder holds any components you want to install for the application. The Roles folder contains security roles you can later assign to the application, an individual component, or a method within the component.
Highlight the Components folder, and then use the click Component in the New subfolder of the Action menu to display the COM+ Component Install Wizard dialog box.
Click Next. You’ll see the Import Or Install A Component page. The Install New Component(s) option helps you to install components you’ve placed on the server but haven’t registered. This is the option you should always use when working with .NET components to ensure you can see all the interfaces and methods they contain. The Import Component(s) That Are Already Registered option helps you to add components that have already been registered on the server. This is the option you’ll choose for updates (in which case, the GUID is exactly the same for the new component as it was for the old one) or when the component has been registered for some other reason. For example, you might be using your development machine as the test server. If you use this option with a .NET component, make sure the component contains the [Guid] attribute for the class to ensure the GUID remains the same from version to version. Generally, you should avoid this option when working with .NET components to ensure your application works as anticipated. Use the Install New Event Class(es) option to create event classes for subscription use. This particular component installation requires special programming that we’ll discuss in Chapter 11.
Click Install New Component(s). You’ll see the Select Files To Install page like the one shown in Figure 2-6. Although you can install components that reside on other machines, you’ll find that components work more reliably if you place the component on a local server hard drive. (As previously mentioned, you’ll probably want to place your custom components in a special place on the server to make them easier to find.) Notice that the folder for the sample component includes both the DLL and TLB files. Always select the TLB file because COM+ won’t know what to do with the DLL file.
Find the component file you want to install. The example uses MyMath.TLB. Highlight the file, and then click Open to complete the selection process. You’ll see the Install New Components page similar to the one shown in Figure 2-7. (You might need to check the Details option to get your dialog box to match the one shown in the figure.) Note that the figure shows what you should see when working with the sample component. The example contains both components and a type library—you’ll need both for COM+ applications. Clicking the Add button at this point would allow you to add another file to the list (along with any components the file contains). Our component is also shown as a COM+ component type, and the wizard has found interfaces within the component. (The wizard won’t tell you which interfaces have been found at this point—we can hope, it found the ones you wanted to expose.) You need to check all these items as part of the component setup.
Click Next. You’ll see the final COM+ Component Install Wizard page.
Click Finish to complete the Install New Component(s) installation process. You’ll see the new component added to the right pane of the Component Services window, as shown in Figure 2-8.
At this point, the COM+ application and an associated component are installed within the Component Services snap-in. However, the component isn’t completely operational yet because we haven’t installed any security for it. Yes, you can use the component at this point—there isn’t any magic about adding security to the COM+ application. However, adding security is essential for creating a COM+ application that works well.
Theoretically, we could get by without adding any security because the application is already protected by the standard Windows security. However, role-based security is one of the features of COM+ that makes life a lot easier for network administrators and developers alike. This is because you can refine the security measures used to protect a component, the interfaces it contains, and the methods required to perform the application’s work. Unlike Windows security, where you have to use a one-size-fits-all approach, role-based security allows you to base security on the work a user will perform.
To add role-based security to the component, you’ll need to create at least one, and preferably two, roles. We’ll call the first role Administrator so that someone logged on as this role will be able to access all the methods within the MyMath component. The second role can be any other value, but for this example we’ll use User. The User role will be able to access just the four math functions.
Highlight the Roles folder, and then click Role in the New submenu of the Action menu to display the Role dialog box.
Type a name for the role, and then click OK. For the example, we’ll use Administrator for one role and User for the second.
Open the Administrators (or Users) folder, and then highlight the Users folder. Click User in the New submenu of the Action menu to display the Select Users Or Groups dialog box shown in Figure 2-9. This is where you’ll choose the users that can access components using the Administrator role.
Type the names of the users or groups you want to include for each role in the field provided. The example uses the Administrators group for the Administrator role and a test user for the User role. Make sure you separate multiple entries using a semicolon and use the proper form for the entries. If you want Windows to do the work, click Advanced and you’ll see a Select Users Or Groups dialog box that will help you find individual users or groups.
Click OK. The selected users or groups will get added to the Users folder for the appropriate role in the Component Services window.
Repeat steps 1 through 5 for the User role. However, in this case, use your own name, a test user name, or the Users group instead of the Administrators group for the Users folder. Figure 2-10 shows a security setup that would be typical for our scenario. Obviously, any production components you create will have a more complex security setup that allows users to access the components you create in specific roles.
I’ve chosen not to implement any form of security within the MyMath component because that would defeat the purpose of using the highly configurable role-based security option. If I had implemented security within the component, any change to the company structure might also mean a change to the code within the component. In most cases, you don’t want to add security to your component anymore; you’ll want to add security by using the Component Services snap-in.
With this change in methodology in mind, let’s see what you’ll need to do to add security to the MyMath component. First you’ll need to enable role-based security. This means making a change at the application level. Right-click the MyMathApp entry, and then choose Properties from the context menu. You’ll see the MyMathApp Properties dialog box. Choose the Security tab of this dialog box, and you’ll see the security options shown in Figure 2-11. This is where you determine what kind of security an application will use.
Caution
You can’t use role-based security with library applications. This feature is designed to work only with server applications. Unfortunately, Windows won’t protect you from adding role-based security to a library application. This means you could make settings changes that cause an application to stop working for no apparent reason. In other words, this is one setting you should check when you have a malfunctioning library application.
There are actually two settings you need to look at. First make sure you check the Enforce Access Checks For This Application option. This setting enforces security at the component, interface, and method levels. Second make sure you allow access checks at both the process and component levels. You can do this by selecting the second option in the Security Level group shown in Figure 2-11. (The figure shows the Security Level properly configured.) You need to select this option if you plan to use role-based security within your components as well. Otherwise, your components will be limited to whatever security Windows provides at the application level.
Now that we have role-based security enabled at the application level, right-click the MyMath.MathFunctions component and choose Properties from the context menu. You’ll see the MyMath.MathFunctions Properties dialog box.
As you can see, the MyMath.MathFunctions Properties dialog box helps you to configure a relatively wide range of component options, including whether the component supports transactions. There are also options for allowing the component to engage in object pooling (normally a good idea with database components) and concurrency. Click the Security tab, and you’ll see the Security tab of the MyMath.MathFunctions Properties dialog box, similar to the one shown in Figure 2-12. Notice that both the roles we’ve created are available for use with this component.
Figure 2-12. Windows will automatically display any roles you’ve created for a COM+ application at all application levels.
Remember that we have role-based security enabled, but as you can see in Figure 2-12, neither of the role-based security options are checked. With the Security tab of the MyMath.MathFunctions Properties dialog box is set as it is, no one can access the component. What you’ll need to do is select the roles that you want to access the component. Let’s assume the Administrator role will have full access to this component. Select the Administrator entry, and then click OK to make the change permanent.
Now, let’s look at the effect of our decision at a lower level of the application. Right-click the _MathFunctions interface (located in the Interfaces folder for the application), and then choose Properties from the context menu. Click the Security tab, and you’ll see the _MathFunctions Properties dialog box. Notice that we still have two options to choose from with regard to role-based security, but that Administrator appears in the Roles Inherited By Selected Item(s) list box. This means you don’t have a choice about the Administrator role—anyone in this role already has access to this interface. You’ll find that the same rule holds true for methods. In other words, everyone in the Administrators group can access everything this component has to offer. On the other hand, the User role still hasn’t been defined.
Right-click the DoAdd entry in the Methods folder, and choose Properties. Click the Security tab. You’ll see the same list of inherited roles and defined roles as before. This time, select the User role and click OK. The User role now has access to the DoAdd() method. Perform the same task for the other three simple math entries: DoSubtract, DoMultiply, and DoDivide.
As with COM, COM+ applications require a proxy on the client machine. The client sees the proxy as the component. Of course, the proxy merely poses as the component and passes anything the client requests on to the server. The method for creating a proxy in COM+ is different from the DCOM method. You actually create an installation program that helps avoid any messy modifications to the registry. Creating a proxy is relatively easy; the following steps show you how.
Open Component Services on the server. Locate the MyMathApp application in the COM+ Applications folder.
Right click MyMathApp, and then choose Export from the context menu. You’ll see the Welcome To The COM+ Application Export Wizard dialog box.
Click Next. You’ll see the Application Export Information page shown in Figure 2-13. This is where you’ll choose the name and type of export application created. We need a proxy application, in this case, so that the installation routine will direct the MyMathApp requests to the server, not to the local machine.
Type a name for the application you want to create. (The example uses the name MyMathAppInstall.MSI, but you can use any name you want.)
Choose the Application Proxy option.
Click Next. You’ll see the final COM Application Export Wizard page.
Click Finish. At this point, the application you need is created; all you need to do is install it.
Locate the MyMathAppInstall.msi file on the client machine. You’ll need to install the proxy application on every machine that will use the component in the COM+ application.
Right-click MyMathAppInstall.msi, and then choose Install from the context menu. An installation dialog will appear for a few moments, and then go away. At this point, you have access to the server-side component through the proxy application. You could create a standard Visual Basic application and use the component without ever seeing the connection between the client and server.
If you open Component Services on the client machine at this point, you’ll see that there’s a new application named MyMathApp. However, this application isn’t the full-fledged application found on the server—it’s an application proxy. Open the MyMathApp Properties dialog box, and you’ll notice you can’t change any of the application options. This application is designed to precisely replicate the server application.
Working effectively with .NET means knowing how to configure the .NET Framework for optimal use. This section of the chapter focuses on the .NET Framework Configuration MMC console. This console helps you manage your .NET components and controls, work with Remoting Services, create a secure environment, and manage configured applications. Each major section of the .NET Framework Configuration console includes a Help screen and at least one link that leads to a task-oriented configuration option, as shown in Figure 2-14. The following sections provide an overview of some of the essential tasks we’ll perform in this book.
Figure 2-14. Each snap-in for the .NET Framework Configuration console provides a help screen as the starting point.
Note
Once you select a link on the Help screen for a particular snap-in, that link remains displayed each time you select the snap-in. To return to the Help screen so that you can select another link, right-click the snap-in entry in the Scope pane and choose View and then Help Topic from the context menu.
The Assembly Cache snap-in help screen displays two links. The first, View List Of Assemblies In The Assembly Cache, displays a list of assemblies in the GAC, as shown in Figure 2-15. Notice that this list includes the version number and locale information for each assembly. This information is important because sometimes an application requires a specific assembly version or locale. The public key token shows how the assembly is signed. Assemblies with the same public key token are signed by the same individual or company. You can also use this list to copy or delete assemblies in the GAC. Simply right-click the assembly in question and choose the appropriate option from the context menu.
The Add An Assembly To The Assembly Cache link on the help screen will display an Add An Assembly dialog box. Select the assembly you want to add, and then click Open. If the assembly has a strong name, the snap-in will add it to the GAC for you. Otherwise, you’ll see an error message.
The Configured Assemblies snap-in manages the binding policy and code-base of the assemblies in the GAC. You won’t see any assemblies in this list for a default .NET Framework installation (at least not as of this writing). However, you can click Configure An Assembly to add an assembly to the list. The following steps show how to configure an assembly.
Click Configure An Assembly in the Configured Assemblies Help screen. You’ll see the Configure An Assembly wizard. This is where you’ll select the assembly to configure. For the purposes of this procedure, I’ll use the MyMath asssembly added to the GAC earlier in the chapter.
Select an assembly to configure. You can manually type the information or click Choose Assembly. When you click Choose Assembly, the snap-in displays the Choose Assembly From Assembly Cache dialog box. Scroll through the list of available assemblies, highlight the one you want to configure, and then click Select. In either case, the Assembly Name and Public Key Token fields will contain the information needed to identify the assembly.
Click Finish. The snap-in will add the assembly to the list of configured assemblies. It will then display a Properties dialog box for the assembly.
Click the Binding Policy tab to assign a version number binding policy to the assembly if necessary. When an application requests an assembly with a version number within the range you select, the GAC will automatically supply the assembly with the version number you provide.
Click the Codebases tab to assign a URI to the assembly if necessary. Whenever an application requests an assembly with a specific version number, the GAC will provide the supplied codebase.
Click OK. The assembly is configured.
Whenever you want to view a list of configured assemblies, click the View List Of Configured Assemblies in the Configured Assemblies snap-in. This option displays a list similar to the one shown in Figure 2-15. In this case, however, the list will contain the name of the assembly, the public key token, and the words "yes" or "no" to reflect the status of the binding policy and codebases configuration.
The Remoting Services snap-in help screen provides access to just one link, View Remoting Services Properties. Click this link, and you’ll see the Remoting Services Properties dialog box. To use this dialog box, select the channel you want to configure. Once you select the channel, adjust the attributes displayed in the attribute list as needed.
We’ll discuss the issue of security several times throughout the book. However, you need to know a few things about the Runtime Security Policy snap-in at this point. First, these policies affect the common language runtime—not the policies of the system as a whole. This means that using this snap-in helps you modify .NET security without affecting the security of the rest of your machine. Second, notice in Figure 2-14 that this snap-in works at three levels:
Enterprise
Machine
User
The Enterprise level is the most encompassing because it affects everyone who connects to the network. The Machine level affects only the current machine, while the User level affects only a specific user.
Each of these levels includes three folders. The Code Groups folder contains policies that affect the execution of code. For example, if you look at the Machine level, you’ll find code groups for each of the zones found in Internet Explorer. Each of these zones will include one or more subzones that also have policies and so on. You can get quite specific about how code runs on a machine using these settings. To modify one of these settings, click the Edit Code Group Properties link.
The Permission Sets folder contains a list of permissions that affect local resources such as files, the network, or hardware. This folder contains entries that group the permissions by area, or you can select the Everything entry to see all the permissions. To see the settings for one of the permissions, right-click its entry and choose Properties from the context menu.
The Policy Assemblies folder contains a list of assemblies that directly affect .NET security. When viewing the contents of this folder, you’ll see the assembly name, the version number, and its public key token. There aren’t any configuration settings in this folder. You can, however, add or remove assemblies as needed to meet your security needs.
In this chapter, you’ve learned about the place of COM+ in the .NET developer’s toolbox. It’s still an important technology for the developer of distributed applications. In most cases, COM+ complements the capabilities that .NET provides, so combining the two makes sense for the present. Eventually, Microsoft will replace COM+ with something that uses .NET directly, but for now, you still need this technology to make some types of distributed applications work.
You’ve also learned about two handy MMC snap-ins. Actually, the developer-should know about most, if not all, of the MMC snap-ins because they all provide handy administration functions. For example, you’ll find the snap-ins provided in the Performance console handy when you want to analyze the performance of your application on various systems. If you haven’t already spent time working with the various MMC snap-ins, you might want to do so now. You’ll want to have a variety of tools at your disposal as you work through the examples in this book.
Chapter 3 shows you how to use COM components in your .NET application. You’ll learn about several tools that come with the .NET Framework that make this job easier. Chapter 3 also helps you understand how .NET interacts with COM. Finally, you’ll learn how to build COM components that not only work well with unmanaged applications, but also interact well with managed applications.