Using the. NET Framework to simplify the release and solve the DLL Hell problem (1)

Introduction

Microsoft®The. NET Framework introduces several new features designed to simplify application release and solve DLL Hell. End users and developers are familiar with version and release issues. These problems will come along with today's component-based systems. For example, each end user installs a new application on their machine and does not expect the existing application to mysteriously stop working. Most developers spend time using Regedit and try to keep all necessary registration items consistent to activate the COM class.

The. NET Framework is based on Microsoft Windows®Based on 2000, The End of DLL Hell written by Rick Anderson and David DSouza, implementing Side-by-Side Component Sharing in Applications (Expanded) by BJ Whalen and Peter Wilson are described in this document .. The NET Framework provides many features described in these two articles, including application isolation and parallel components for applications built on the. NET platform. You will understand the version support provided on the. NET platform, which makes local Windows applications more tightly integrated.

This article introduces the concept of assembly and describes how. NET uses assembly to solve version and release problems. We will discuss in particular how compilation is built, how to name it, and how compilers and general-Language Runtime use assembly to record and enhance version dependencies between application fragments. We will also discuss how apps and administrators can customize version behavior using the version policy we call.

After the compilation is introduced and explained, several release schemes will be displayed to help you understand the various packaging and distribution options provided in the. NET Framework.

Problem description

Version

From the customer's perspective, the most common version issue is what we call the DLL Hell issue. To put it simply, DLL Hell means that when multiple applications attempt to share a public component (such as a dynamic connection library (DLL) or a Component Object Model (COM) Class) A series of problems. The most typical scenario is that an application will install a new version of the shared component, which is not backward compatible with the existing version on the machine. Although the newly installed application runs normally, applications that originally relied on the previous version of shared components may no longer work. In some cases, the cause of the problem is even more unpredictable. For example, when a user browses some Web sites, a Microsoft ActiveX®Control. If you download the control, it replaces any version of the control on the machine. If an application on the machine uses this control, it is likely to stop working.

In many cases, it takes a long time for the user to find that the application has stopped working. It is often difficult to remember when machine changes affect the application. The user may recall that some things were installed a week ago, but the installation has no obvious association with the current status. Even worse, few diagnostic tools are now available to help users (or their technical support staff) determine what's wrong.

The reason for these problems is that the version information of different components of the application is not recorded or enhanced by the system. Moreover, changes made by the system for an application will affect all applications on the machine-it is not easy to create an application completely isolated from the changes.

One reason it is difficult to establish an isolated application is that the current runtime environment only allows installation of separate version components or applications. This restriction means that the component writers must write their code in a backward compatible manner, otherwise they may have the risk of terminating existing applications when installing new components. In fact, if possible, it is very difficult to write code that is always backward compatible. In. NET, the concept of side by side is the core of the version issue. "Side by side" is the ability to run the same component of different versions on the same machine at the same time. Programmers do not have to maintain strict backward compatibility when using parallel components, because different applications are free to use different versions of a shared component.

Release and Installation

Installing the application is a multi-step process. Generally, installing an application involves copying many software components to a disk, and performing a series of registration items describing those components in the system.

The separation of entries in the Registry and files on the disk makes it very difficult to copy applications and uninstall them. In addition, the relationship between many items required to completely describe a COM class in the registry is very loose. These items often include items of the Union class, interface, Type Library, and DCOM app ID, and do not involve any items placed in the registry document extension or component category. Always manually synchronize these items.

Finally, the registration footprint is required to activate any COM class. This greatly complicated the process of publishing distributed applications because appropriate registration items must be performed on each client machine.

Another common problem today is that it is unrealistic to update a running application. This is the biggest problem for Web applications. Web applications must stop working and restart to update the COM class used by the application.

These problems are mainly caused by component descriptions separated from the component itself. In other words, applications are not self-described and independent.

Features of the Solution

The. NET Framework must provide the following basic capabilities to solve the problem just described:

The application must be self-described: The self-described application removes the Registry dependency and can be installed and simply uninstalled and copied without any impact.

Version information must be recorded and enhanced: Version support must be built inside the platform to ensure that the appropriate version of the dependency is loaded at runtime.

Remember "correct configuration known last time": When an application runs successfully, the platform must provide the ability to remember the components that work together-including their versions -.

Parallel components must be supported: Allow multiple versions of components to be installed and run on the machine at the same time, and allow callers to specify the version they need to load to replace the version that is unconsciously forced .. The NET framework allows multiple versions of the framework to exist on a single machine at the same time. This greatly simplifies the upgrade because the administrator can choose to run different applications on the. NET Framework of different versions if needed.

Applications must be isolated: the. NET Framework must be simplified (by default) to write applications that are not affected by changes to other applications on the machine.

Assembly: Building Blocks

Compilation is the building block of the. NET Framework used to solve the just-described version and release problems. Assembly is the unit of release for types and resources. In many ways, the compilation is the same as the current DLL. In essence, assembly is a "logical DLL ".

Assembly is self-described through the metadata call list. Just like. NET's use of metadata to describe the type, it also uses metadata to describe the assembly of the inclusion type.

Compilation is not just about publishing. For example, the version in. NET is completed at the Assembly layer-without any reduction, just like a module or type of version. Compilation is also used to share code between applications. An assembly that contains a type is part of the type flag.

The code for accessing the security system uses the assembly in the kernel of its license model. The assembler records a set of permissions required to run the code in the list, and then the Administrator authorizes the permission to the Assembly-based code, which contains the code.

Finally, assembly is also the core of the type system and runtime system, in which they create a visible boundary for the type and service as the runtime range for resolving the reference type.

Assembly List

The list clearly includes the following compilation data:

Identifier: An assembly identifier consists of the name, version number, and option culture.

File List: The list includes the list of all files that constitute the assembly. For each file, the encrypted information of its name and content is recorded when a list is created. This information is verified at runtime to ensure consistency of the publishing unit.

Referenced assembly: the relationship between the assemblies is stored in the collection assembly list. The slave information includes the version number, which is used to ensure that the correct version is loaded during runtime.

Output type and resource: visible options available for types and resources include "visible only in my assembly" and "visible to callers outside of my assembly ."

License requirements: the compilation license requirements are divided into three groups: assembly operation requirements, needs, but the compilation has some functional requirements, even if not authorized, and the compiler does not want to compile the authorization requirements.
The Ildasm SDK is helpful for viewing code and metadata in the Assembly. Figure 1 shows a list of examples using Ildasm .. Assembly indicates assembly and. assembly extern contains information about dependencies of other assemblies.

Figure 1. List of samples displayed in IL Disassembly

Assembly structure

So far, the Assembly is mainly described by logical concepts. This section describes how they are physically embodied to help you make Assembly more specific.

Generally, an assembly consists of four elements: Assembly metadata (list), metadata description type, media language (IL) code that implements this type, and a group of resources. Not all of these appear in each assembly. Only lists are strictly required, but types or resources need to compile some important functions.

There are several options about how these four elements can be packaged. For example, Figure 2 contains the entire Assembly: List, type metadata, IL code, and resources.

Figure 2. DLL containing all Assembly elements

In another case, the content of an assembly may be divided into multiple files. In Figure 3, the author chooses to separate some useful code into a different DLL, and keep a large resource file (this is a JPEG file) in its original file ). One reason for doing so is to optimize the download of code .. . NET Framework only downloads files when referenced. Therefore, if the Assembly contains frequently accessed code or resources, splitting them into separate files will improve the download efficiency.

Figure 3. Split assembly elements into multiple files