Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Configuring Assemblies
As the .NET Framework matures, Microsoft will introduce new versions. In addition, your custom assemblies will undoubtedly undergo revision. Eventually, you'll end up with applications that request everything from the latest version to the first version of a particular assembly.
The use of side-by-side installation means that the Common Language Runtime (CLR) can honor every assembly request, as long as the target system has the required version of that assembly installed. At some point, administrators are going to remove older versions of these assemblies from systems, which means that some applications could fail unless the system provides a means of honoring the request. This need brings a binding policy into play. The binding policy tells the CLR that it's okay to use a newer version of an assembly to honor requests for an older version.
In addition to the problem of older assemblies, there's the issue of locating and installing newer versions of an assembly. Microsoft assumes that you'll want the system to download the newer version from a central location that need not be on the Internet. Setting a code base for an assembly tells the system where to look for updates.
You configure both of these options using the entries in the Configured Assemblies folder. In both cases, click Configure an Assembly. When you see the Configure an Assembly dialog box, select one of the assembly identification options. You can choose an assembly from the GAC or enter the assembly information by hand. (Choosing the assembly from the GAC is much easier.) Click Finish and you'll see a Properties dialog box for the assembly, similar to the one shown in Figure 2.
Figure 2 shows the Binding Policy tab. The entry in the figure tells the CLR that whenever an application requests the 1.0 version of this assembly, the CLR should load the newer 1.0.1665.28688 version instead. You can create as many binding policies as needed to ensure that applications run flawlessly.
)
Figure
2 Configure assemblies as needed to respond to specific application
needs.
The Codebases tab in the dialog box lets you define a location for downloads. Like the Binding Policy tab, this tab displays two columns. The first column contains the assembly version. You can enter as many assembly versions as needed to support the applications you create. The URI column lists the location for the assembly; you can include network or even local folders by specifying the file protocol like this:
file:///D:/MyMathClass/MyMathClass.dll
To remove or modify a configuration entry, click View List of Configured Assemblies in the Configured Assemblies folder. Right-click the assembly entry and choose Properties from the context menu to modify the current settings. Right-click the assembly entry and choose Delete to remove the assembly from the configured list.
Changing Assembly Security
Normally, you'll want to use code to set the security level of an assembly. Using this technique means that the assembly is ready to use the moment someone installs it. In the past, the security level of an assembly often didn't matter because Windows wasn't very good at enforcing security policies. However, starting with Windows XP Service Pack 2, security policies matter a great deal. This change in Windows capability means that sometimes you need to set the security level of an assembly manually, as described in the following steps:
Select the Runtime Security Policy folder. This folder contains the security settings for the assemblies.
Click Increase Assembly Trust to open the Trust an Assembly dialog box.
Select the option Make Changes to This Computer; then click Next.
When the wizard asks which assembly you want to trust, locate the assembly file that you want to change. Click Next.
When the wizard asks what level of security you want to assign to the assembly, set the slider for this assembly to Full Trust. Click Next and then verify the settings in the Completing the Wizard dialog box.
Click Finish. The assembly is now ready for use at its current location. If you move the assembly, you must also reset the security.
Working with Code Groups
One of the security principles that the .NET Framework uses is the idea of an assembly presenting evidence to the CLR that the assembly meets the requirements of the security policy for the system—essentially, the law for that system. One of the more important pieces of evidence that an assembly can provide is membership in a particular code group. The assembly enjoys the same privileges and restrictions that the code group enjoys, so proof of membership is important.
The .NET Framework comes with only one code group by default: the All_Code group. The Enterprise, Machine, and User policies all support this code group, and you'll generally use it for all local programs. However, you can modify how the code groups work and even add new code groups as the need arises. Any new code group you add will appear below the All_Code group in the hierarchy. In fact, Microsoft adds a few of these entries to the Machine policy for you, as shown in Figure 3.
When you first select Runtime Security Policy, <Level>, Code Groups, All_Code in the left pane of the .NET Configuration tool, you'll get a help screen. This screen contains options for adding new code groups or configuring the existing code group, as shown in Figure 3. (This figure also shows the location of the All_Code entry in the hierarchy.)
)
Figure
3 Add or edit code groups using this help screen.
You can use one of three methods to create a new code group. Click the Add a Child Code Group link to open a Create Code Group dialog box. This dialog box contains two of the methods for adding a new code group: first, an option to create the code group manually; second, an option to import an XML file that contains the code you want to use. The third method is to right-click an existing code group and choose the Duplicate entry from the context menu. This technique creates a code group with the same characteristics as the parent.
If you choose to create a code group manually, you pass through several dialog boxes. Each dialog box asks a question about the new code group, including the condition type (such as Application Directory, Zone, or Hash) and the permission set (such as Full Trust, Execution, or Internet). Editing a code group means changing features such as the condition type and the permission set. When you click Edit Code Group Properties on the help screen, you get a Properties dialog box that you can use to determine how the code group will work with the policy levels. The first check box lets you set the code group exclusively to use permissions associated with the permission set for the code group. The second tells the CLR not to evaluate policy levels below the existing policy level. In other words, this check box creates an exclusive code group.
Creating and Defining Permission Sets
The .NET Framework comes with a standard set of permissions. You can create additional permission sets as required to meet specific programming needs. In addition, you can modify the definitions for existing permissions. However, modifying a current permission isn't a good idea because that action will change the default meaning of the permission and could cause applications written by other developers to fail. (The CLR prevents you from changing .NET Framework–specific permission sets.)
You have the same options for creating a new permission set as described in the preceding section, "Working with Code Groups." Creating a new permission manually displays the Create Permission Set dialog box. The first screen asks for a name and description for the permission set. The second screen asks you to define the permission for the permission set, as shown in Figure 4.
)
Figure
4 To avoid security breaches, define the permissions carefully for your new
permission set.
Whenever you add a new permission, the .NET Configuration tool displays a Permission Settings dialog box that helps you configure that particular permission. The dialog boxes vary by permission. For example, the File IO permission includes a setting that lets you define individual permissions for each drive you want the permission set to access, or you can grant unlimited drive access. You can click Import to import an XML file containing the permissions you want to use. Custom permission sets include a help screen that lets you view, change, and rename the permission set.
Defining Policy Assemblies
Policy assemblies contain the code used by the CLR to evaluate the evidence presented by an object to obtain a permission. The default .NET Framework configuration is all you need, unless you design a special policy that requires additional code. When you create a unique policy, you must add the assembly to the appropriate list, or the evaluation will always fail. Unfortunately, you may find that .NET is less than helpful in telling you about this problem. It always appears as a security error.