C# ПІДРУЧНИКИ / c# / MS Press - Msdn Training Programming Net Framework With C#

Publisher-policy resolution allows shared-component vendors to make compatibility statements among different revisions of their software. These perassembly configuration files are distributed as strong-named assemblies and are installed into the global assembly cache as part of a service pack-style update. Any binding redirects that are specified by the publisher-policy file are then applied to the reference, which is then subject to administrator-policy resolution. Because publisher-policy assemblies affect all applications on the system, it is important that these assemblies are installed separately from the application.

Administrator-policy resolution is the final—and the strongest—stage in the binding policy-resolution process. The administrator-policy file is located in the

WindowsDirectory\Microsoft.NET\Framework\v1.0.FinalBuildNumber\ CONFIG directory and is called Machine.config. This file has the same XMLbased schema as the policy files that are used in the two previous stages of policy resolution. Administrator policy affects all assembly bindings that occur on the system and can never be bypassed.

Version Policies

All versioning of assemblies that use the common language runtime takes place at the assembly level. The specific version of an assembly and the versions of dependent assemblies are recorded in the assembly’s manifest. The rules that specify the acceptable versions of an assembly are called version policies. Version policies are expressed in configuration files.

Using Configuration Files to Override Version Policy

According to the default version policy for the runtime, applications run only with the versions that they were built and tested with unless these versions were overridden by explicit version policy in configuration files. These configuration files, which include the application configuration file, a publisher policy file, and the machine’s administrator configuration file, provide the means for overriding the version policy that is recorded in the assembly manifest.

Binding to a Specific Assembly Version

In a configuration file, you can specify a version policy that instructs the runtime to bind to a specific version of an assembly that you want the application to use. This specific version policy allows you to bind to a different version of an assembly than the version that is recorded in the assembly manifest of the calling assembly. In particular, the bindingRedirect tag can be used to redirect the reference to a different version of a shared assembly, by overriding the version in the original reference with this newer version.

The following option says that for any assembly reference from version 2.0.0.0 through 2.0.0.9, the version that should instead be used at run time is 2.0.1.0:

<bindingRedirect

oldVersion="2.0.0.0-2.0.0.9" newVersion="2.0.1.0"

/>

This option allows an administrator to reconfigure an application without having to have it recompiled.

Code Access Security and Role-based Security

Code access security uses permissions to control the access that code has to protected resources and operations. It helps to protect computer systems from malicious mobile code and provides a way to allow mobile code to run safely.

Role-based security provides information that is needed to make decisions about what a user is allowed to do. These decisions can be based on the user’s identity, role membership, or both.

A more detailed discussion of security is outside the scope of this course. For more information about security, see “Securing Your Application” in the .NET Framework SDK documentation.

Additionally, Course 2350A, Securing and Deploying Microsoft .NET Assemblies (Prerelease) covers code access security and role-based security in greater detail.

Localization

To localize an application, you typically perform the following steps:

1.Separate your default resources from the code, and specify the localized text in a text file.

2.Compile the text file into a .resources file.

3.Package your default resources in the main assembly by using the C# compiler.

4.Create satellite resource assemblies, including satellites for .NET Framework cultures, by using the Alink tool.

5.Deploy the satellites to a directory structure underneath the main application.

6.Write the code to access the resources at run time.

For more information about localization, see the .NET Framework SDK documentation.

The following command lists the contents of the global assembly cache:

gacutil /l

MSIL Disassembler (Ildasm.exe)

You can also explore the namespaces in files that come with the runtime or in files that you or others create by using the command-line MSIL disassembler. To open a window that displays information about System.Data.dll, use the following command:

>ildasm System.Data.dll

Each of the namespace nodes represents a separate namespace, which can be expanded to explore the class objects and their methods and properties.

The MSIL disassembler also features a number of command-line options, which are particularly useful when you want to redirect output to the console or to a text file for subsequent analysis.

Tip Place a shortcut to Ildasm.exe in your SendTo folder.

Strong Name Tool (Sn.exe)

When working with shared components, you can use the Strong Name (Sn.exe) command-line tool for several purposes. For example, you can use the tool to generate a new public-private key pair and write that pair to an output file, as follows:

sn -k <outfile>

Native Image Generator (Ngen.exe)

The Native Image Generator creates a native image from a managed assembly and installs it into the native image cache on the local computer. Running Ngen.exe on an assembly allows the assembly to load faster, because it restores code and data structures from the native image cache rather than generating them dynamically.

Pre-compiling assemblies with Ngen.exe can improve the startup time for applications, because much of the work required to execute code has been done in advance. Therefore, it is more appropriate to use Ngen.exe for client-side applications where you have determined that the CPU cycles consumed by just- in-time (JIT) compilation cause slower performance.

Because there are many factors that affect the startup time of an application, you should carefully determine which applications would benefit from the use of Ngen.exe. Experiment by running both a JIT-compiled and a pre-compiled version of a candidate assembly in the environment in which it will be used. This will allow you to compare the startup times for the same assembly executing under different compilation schemes.