Study Notes on programming. NET components (12)

Custom Version Policy

. Net allows the Administrator to override the defaultProgramSet resolution policies and provide custom version binding policies. You can provide custom policies for individual applications, but only affect the binding of a specific application to private or shared assembly. You can also provide custom policies within the local machine scope to bind each application on the local machine to the GAC and specify the shared Assembly mode. The administrator can choose to create a custom policy for various reasons. However, these tasks are usually submitted for use in a new or improved server assembly version, and the provider ensures compatibility with earlier versions .. Net default version binding and parsing policies always try to read the "correct" version compiled with the client application. If you replace a strong private copy with a new version, the Assembly parser will still try to read the earlier version compiled with it and throw an exception when the read fails, even if the new version has been installed in GAC. To handle these situations,. Net allows the Administrator to redirect the requested version to different versions .. . Net allows the Administrator to specify a specific location for a specific version to replace the default location (first, GAC and then application directory ). In this way, the administrator can use the existing private assembly in other applications, or redirect the reading location of the Assembly in the GAC.

Application custom policy

The. NET Configuration tool has a top-level folder called "application. If you want to provide a custom policy for an application, add it to the folder (right-click the "application" folder and choose Add. Net program file ). The added application contains a sub-folder called "configured assembly. Click this folder. On the right panel of the. NET Configuration tool, the configured assembly is displayed, and whether custom version binding or based onCodePolicy:

The configured assemblies folder contains all the assemblies used by the application that have custom policies. To provide custom policies for an assembly, you must add them to the folder (right-click the configured Assembly folder and choose Add. Net Assembly file ):

You can select the assembly to be configured from the list of all sets used by GAC or applications (generated by reading the Application List. Note: Since the list shows all the used assemblies, only private assemblies with friendly names are included. It makes no sense to select them, because the Assembly parser ignores the version issue when the Assembly does not have a strong name. In the list, it is easy to tell whether an assembly has a strong name: a strongly-named assembly has a value in the Public Key tag column:

Custom version binding policy

Once an assembly is selected, the. NET Configuration tool immediately displays the attributes of the Assembly. You can specify a custom version binding policy in the binding policy tag. Tags include the redirection list of any version. The administrator can specify a specific version to redirect to another specific version, or specify a range of redirection versions, you can also specify a new version to redirect to the old version (for example, a defect is found in the new version ). The only requirement is to use the. NET Version Number Format major. Minor. Build. Revision to specify the version number. The administrator can add any number of required version redirect requests.

Customize basic code policies

In the basic code label of the Assembly property, the administrator can find the version of the Assembly where the Assembly parser is located:

The administrator can redirect requests for private or shared assembly to any location. For example, if the Assembly parser needs to read version 3.2.1.0 of an Assembly and this version has basic code redirection, the parser will find the assembly version at the redirection location, even if an appropriate version exists in a private directory or GAC. Similarly, the only requirement is to specify the version number in. Net format and the location in URL format. The administrator can add any number of required basic code redirect requests.

Application configuration file

When a custom policy is provided for an application, the configuration information defined by the. Net Configuration tool is saved in a special configuration file in the application folder. This file is changed to <Application name>. config. The configuration file contains custom policy information in XML format. This configuration file allows you to copy application custom policies on multiple machines:

Global custom policy

The administrator can also provide a global custom policy for the Assembly in GAC. Add the Assembly from GAC to the "configured assembly" folder of the. NET Configuration tool, and specify the custom version binding and basic code redirection for the Assembly. The specified method is the same as specifying a custom policy for a single application. Note that the global custom policy applies to applications on the local machine. In addition, global custom policies are applied to the downstream, that is, the application will first apply its own custom policies and then apply the global custom policies. For example, assume that an application is generated in version 1.0 of A Class Library. The application installs a custom policy to request version 2.0 instead of version 1.0. In addition, assume that there is a global custom policy on the local machine to redirect version 2.0 requests to version 3.0 of the class library. When the application runs in this scenario, it uses version 3.0 of the class library.

When a global custom policy is provided, the configuration information defined by the. Net Configuration tool is saved in a special configuration file acting on the entire computer. This file becomes machine. config. The path is the <Windows Folder> \ Mircrosoft. Net/frameowork \ <version number> \ config folder. The configuration file also contains global custom policies in XML, and allows you to copy application custom policies on multiple machines.

CLR version

. The strict and mandatory compatibility of the. NET version raises an interesting question: if an application uses.. Net version 2.0 is generated when. when the 3.0 version of net is available, the application will not take advantage of the 3.0 version improvement. The reason is that the Application List contains the version number of the dependent assembly, including Clr and application framework .. Net assembly is strongly named, so the Assembly parser will stick to the matching of the correct version. To overcome the version compatibility of your own assembly,. NET must provide a set of different basic rules, which are complex. The correct CLR versions used by components in a class library or EXE may be diverse. It depends on the compiled version, available. Net version, and application version policy.

The. NET architecture tries to strike a balance between creating a new version and supporting existing applications. In the end, it is up to the application provider to decide whether to support a specific CLR version. This marks a change in concept: Microsoft no longer absolutely guarantees forward and backward compatibility. Correspondingly, Microsoft promises to make every effort to be backward compatible and will point out where it is incompatible. This means that a new. Net version is not fully backward compatible. One exception to this guarantee is security-Microsoft intentionally makes changes in the new. Net version to handle security vulnerabilities.

Concurrent execution of CLR

Now Clr and various. NET application frameworks are composed of many sets, which can be considered as a separate version unit. Multiple versions of these units can coexist on any computer. This is called CLR "side-by-side execution (parallel execution )". Parallel Execution is feasible because. NET is deployed in GAC and GAC supports parallel execution of multiple versions of the same assembly. Therefore, different. NET applications can use different. Net versions at the same time. You can also install a new version of. Net or remove an existing version. The parallel method reduces the possibility of affecting another application when an application is installed, because earlier applications can still use earlier. Net versions. Even so,. Net parallel execution allows you to select when to upgrade to the next. Net version, rather than getting it out of the latest CLR version.

Version unification

All. NET applications are hosted in an unmanaged process that reads CLR DLLs. This unmanaged process can use the correct version of each CLR assembly. In addition, CLR version numbers govern which. NET application framework version can be used, because they are considered as a separate version unit. In fact,. Net always runs in a Framework Assembly stack of Unification 1, called "version unification )". The requirement for unification is that the CLR and. NET application frameworks are not designed for mixing and matching. That is to say, some assemblies cannot come from Version 1.1, while some are from version 2.0.

Typically, a. NET application includes a separate EXE application Assembly used to start the process and read multiple potential other assembly into the process. Unification means that a process includes a hosted application. Both the EXE application assembly and the Assembly it reads use the same. Net version. In this process, the CLR and application framework versions are selected by the EXE used to start the process. Other read assemblies do not have permission to ask questions. For example, in the first release of. Net (. NET 1.0), all the Assembly versions are 1.0.3300.0. All the Assembly versions in the second release of. Net (. NET 1.1) are 1.1.5000.0. If both versions are installed on a computer. When an EXE Assembly uses. Net version 1.1.5000.0, all the Assemblies read through it use version 1.1.5000.0, even if they are compiled using version 1.0.3300.0. This is correct because. net1.1 is backward compatible with Version 1.0. However, if the EXE assembly version 1.0.3300.0 is selected, all the Assemblies read through it will use version 1.0.3300.0, even if they require new features of version 1.1.5000.0. In this way, the application may fail.

Note: Avoid using custom version binding policies to override the same version. It will lead to uncertain results.

Specify a CLR version

On a given computer, there can be any combination of CLR versions. Applications can implicitly depend on the default version to determine the policy, or explicitly provide configuration information to indicate the supported CLR versions.

Bind the default version

If an application does not indicate which version of CLR is required by. net, the application actually informs. Net that any compatible CLR version is allowed. In this case,. Net detects the CLR version compiled with the application and uses the latest CLR compatible version on the local machine. To this end,. NET must know which CLR version is backward compatible with other versions. Now, Microsoft believes that all new. Net versions should be backward compatible. Note that CLR backward compatibility is different from forward compatibility. Backward compatibility is a question about whether an earlier version of the Assembly can be executed on a newer version. Forward compatibility is a question about whether a later version of the compiled assembly can be executed on a later version. Backward compatibility is mainly used to change the type definition and type behavior of products. Forward compatibility is controlled by the metadata version .. NET 1.0 and. NET 1.1 have the same metadata version, so they are both backward and forward compatible .. NET 2.0 has a new metadata version, so it only considers backward compatibility --. NET 2.0 Assembly requires. NET 2.0 runtime.

The following table describes the CLR version compatibility matrix. The left column lists the CLR versions compiled with the Assembly, and the other columns list whether the Assembly can run on other CLR versions:

Assembly \ CLR version	1.0	1.1	2.0
1.0	+	+	+
1.1	+	+	+
2.0	-	-	+

A similar compatible table is maintained in the registry. This table is used when. Net decides which. Net version is provided to the application (the highest available compatible version is used by default ).

Supported CLR versions

Using the default version may cause the application to run on an untested CLR version, leading to uncertain behavior. If you do not want your application to rely on the default version binding policy and have a definite behavior, you can provide an explicit version configuration. In this case, the application must use the startup tag with the supportedruntime attribute in its configuration file to indicate which CLR version is supported:

Generally, you should not add the CLR versions that have not passed the test and verification to this list to ensure version compatibility. The order listed by the CLR version indicates the priority used .. Net will try to provide the first CLR version to the application. If this version is unavailable at the current level,. NET will continue to try the next version in the list. If the specified version is not available,. Net rejects the application and displays a message box asking you to install the latest supported version specified in the configuration file. Note that startup indicates overwriting any. net can provide the default behavior, which means that even if another compatible version is available on the local machine, if it is not listed in the configuration file ,. net will refuse to allow applications in this version.

 

According to the English translation of the original version, please do not correct the deficiencies and errors. Thank you :)