Use the. NET Framework to simplify the release and solve the DLL Hell problem (2)

Version and sharing

A main purpose of DLL Hell is to share the model currently used in a component-based system. By default, individual software components are shared by multiple applications on the machine. For example, if one installer copies a DLL to the system directory or registers a class in the COM registry, the code will potentially affect other applications running on the machine. In fact, if an existing application uses the previous version of the shared component, the application automatically uses the new version. It is certainly better if shared components are strictly backward compatible, but if not, it is difficult to maintain backward compatibility in many cases. If backward compatibility is not maintained or cannot be maintained, side effects during installation of other applications often lead to application interruption.

One principle of the. NET design policy is to isolate components (or assemblies ). Isolating an Assembly means that an assembly can only be accessed by one application-not shared by multiple applications on the machine and cannot be affected by changes to the system by other applications. Isolation gives developers absolute control over the code used by the application. Isolation, or application-specific Assembly is expected to be the default in. NET applications. The trend of isolation components has started with the introduction of. local files in Microsoft Windows 2000. This file is used to locate the required components so that OS Loader and COM are first searched from the application directory. (For more information, see Implementing Side-by-Side Component Sharing in Applications ).)

However, in some cases, it is necessary to share the Assembly between applications. Obviously, each application has its own copy of System. Winforms, System. ASP, or common Web table controls, which makes no sense.

In. NET, sharing code between applications is a clear decision. Shared Assembly requires additional requirements. In particular, shared Assembly should support the same assembly. Multiple versions must be installed and run on the same machine, or even in the same process at the same time. In addition, shared Assembly requires stricter naming. For example, a shared Assembly must have a globally unique name.

The need for isolation and sharing leads us to consider two types of assembly. This is a rather loose collection, and there is no actual structure between the two types of assemblies, but how they are used is different: dedicated to an application or shared with many applications.

Application-specific Assembly

Application-specific assembly is only visible to an application. We expect this is the most common case for. NET applications, because the. NET Framework helps establish applications that are isolated from system changes caused by other applications.

The naming requirement for dedicated assembly is simple: the Assembly name must be unique in the application. There is no need for a globally unique name. Keeping names unique is not a problem because the application developer has full control over which assembly is isolated from the application.

Application-specific assembly is deployed in the application directory structure that uses them. Private assembly can be directly stored in the application directory or its subdirectory. The runtime of the common language is searched for by a process called probing. "Probing" is a simple ing between the Assembly name and the file name that contains the list.

In particular, the general language runtime records the Assembly name in the Assembly reference, append ". dll" and find the file in the application directory. There are some variables in this solution, where the runtime will access the subdirectory named by the Assembly or the subdirectory named by the Assembly style. For example, a developer deploys an assembly containing resources located in Germany in a subdirectory called "de" and deploys resources in a subdirectory called "es.

As described above, each assembly list contains version information about its link. The version information is not enhanced for dedicated compilation because developers have full control over the compilation deployed to the application directory.

Shared assembly

The. NET Framework also supports the concept of shared assembly. Shared assembly is used by multiple applications on the machine. Using. NET, code between shared applications is clearly determined. Shared assembly has some additional requirements to solve the sharing problems we have experienced. In addition to supporting the parallel expression described earlier, there are many strict naming requirements for shared assembly. For example, a shared Assembly must have a globally unique name. In addition, the system must provide "name protection"-more specifically, to prevent the use of the author's Assembly name. For example, assume that you are a grid control manufacturer and released your assembly version 1. As a compilation, you must be sure that no one else can publish an assembly called version 2 or your grid control .. . NET Framework supports these naming requirements through the technology called shared names. (Detailed description in the next section ).

Generally, application writers do not have the same level of control over the shared Assembly used by the application. Result: The version information is checked every time the shared assembly is referenced. In addition, the. NET framework allows applications and administrators to overload shared Assembly versions used by applications by specifying version policies.

Shared assembly is usually deployed to the global assembly library. The Global Assembly library is a machine-wide assembly library for multiple applications. Using this database is not necessary, but it has many advantages. For example, automatic parallel storage of multiple versions of assembly is provided. In addition, administrators can use this library to deploy defect fixes or security patches to be used by applications on each machine they need. In this solution, configuration assembly to global assembly storage can affect multiple applications on the machine .. The. NET Framework uses the Version Policy (described later) concept to solve the problem of sharing regions in the system, such as % windir % system32.

To add an assembly to the database, you must specify the Administrator action. In fact, the installation process must have "administrator privilege ". Assembly is never influenced by the end of storage as a side to run an application, nor is it any storage of shared Assembly currently working. In the Visual Studo. NET time frame, the Windows Installer is updated to understand the Assembly and Assembly library. This means that all functions of the Windows Installer can be used, for example, installation by using a. NET application and application recovery.

The. net sdk includes two tools for compiling libraries. The first is the AL tool, which allows you to add an assembly to the library. AL facilitates development and testing. It does not need to create an entire Windows installation package and add an assembly to the library. Use the/install switch to add an assembly to the database:

Al/install: myassembly. dll
The second tool is Windows Shell Extension, which allows you to use Windows Explorer to operate the library. Figure 4 shows the view of the global assembly library.

Figure 4. Global Assembly Library

Share Name

The shared name is used to combine strict naming requirements with shared assembly. The shared name has three goals:

Unique name: Shared Assembly must have a globally unique name.

Prevent name impersonating: as a developer, you do not want to publish a subsequent version of your Assembly, whether unexpected or intentional.

Provide reference identity: When an assembly is referenced, the shared name is used to ensure that the loaded Assembly comes from the desired publisher.
The shared name is encrypted with a public key. Generally, the process is as follows: the assembler generates a pair of keys (or uses an existing one), tags the files containing the Private Key List, and provides the caller with a public key. When the Assembly is referenced, the caller records that generate a public key corresponding to the strong-name private key. Figure 5 outlines how the process works during development, including how keys are stored in metadata and how signatures are generated.

This solution is called "Main" assembly, which references an assembly called "MyLib. MyLib has a shared name. The important steps are as follows.

Figure 5. Implementation of the shared name Process

The developer calls the compiler passed in the key pair and a set of Assembly source files. A key pair is usually generated by an SDK tool called SN. For example, the following command generates a new key pair and stores it in the file:
Sn used MyKey. snk
Most compilers use Assembly as part of the editing step. The following is an example of the C # command, which accepts the key pair and signs the Assembly:

Csc/t: library math. cs/a. keyfile: MyKey. snk/a. version: 1.0.0.0
When the compiler generates an assembly, the Public Key is saved in the list as part of the assembly identifier. Including the public key as part of the identifier to provide a globally unique name for the Assembly.

After the Assembly is generated, the files containing the list are marked by the private key. The result signature is saved in the file.

When the compiler generates the Main assembly, the public key of MyLib assembly is saved in the Main list as part of MyLib reference.
At runtime, the. NET Framework has two steps to ensure that the shared name gives developers the desired benefits. First, verify the shared name signature of MyLib when the Assembly is installed in the global assembly library. (The signature verification option that is not configured in the library is also available .) Verify the signature to ensure that the content of MyLib has not changed since the compilation was established. The second step is to verify that the public key saved as part of the Main reference MyLib matches the public key of a part of the MyLib identity. If these keys are the same, the author of Main can ensure that the loaded MyLib version comes from the same publisher. The publisher has compiled the MyLib version of Main. When MyLib is referenced by Main, the key equivalent check is completed at runtime.

The term "signature" is often associated with Microsoft Authenticode. Understanding the shared name and Authenticode does not matter. These two technologies have different goals. In fact, Authenticode indicates the level of trust in the issuer, but the sharing name is not. There is no authorization license or third-party signature authorization associated with strong names. In addition, the shared name signature is usually carried out by the compiler itself as part of the compilation process. However, there are also utilities for signing in the SDK.

Another item worth considering is the "test signature" project. Compilation writers often cannot access private keys that require full signatures. Most companies protect the storage of these keys, which can only be accessed by a few people. As a result, the. NET Framework provides a small number of "test signature" technologies during development, and then "real signature ".

Version Policy

As described above, each assembly list records the version information of each link on which it is created. However, there are some scenarios where the writers or administrators of application programs need to run in different relational versions at runtime. For example, the Administrator should be able to release the troubleshooting version without re-compiling each application for this modification. In addition, the Administrator must be able to list the detailed versions of the compilation that have never been used due to security vulnerabilities or service faults .. . NET framework enables this flexibility in version binding through version policies.

Assembly version number

Each assembly has a version number consisting of four parts as part of its identifier (that is, some assembly versions 1.0.0.0 and 2.1.0.2 are completely different identifiers related to the class loader ). Versions that are part of the identifier are used to differentiate the version of the Assembly used for parallel purposes.

Developers and administrators must understand the version structure, because it is the key to how to enhance the version relationship between Assemblies during common language runtime.