ado| data simplifies publishing and resolving DLL Hell issues using the. NET Framework
Steven Pratschner
Microsoft Corporation
September 2000
Summary: This article describes the assembly concepts and explains how the. NET Framework uses the assembler to resolve versioning and publishing issues.
Directory
Brief introduction
Problem description
Characteristics of the solution
Assembly: Building Blocks
Versions and shares
Version Policy
Release
Summary
The Microsoft®.net framework introduces several new features designed to simplify application publishing and resolve DLL Hell. Both end users and developers are familiar with versioning and publishing issues that can be accompanied by today's component-based systems. For example, each end user installs a new application on their machine, not expecting an application to mysteriously stop working. Most developers spend their time using Regedit, trying to keep all the necessary registration entries consistent in order to activate a COM class.
The design principles and implementation techniques used in the. NET Framework to resolve DLL Hell issues are based on the Microsoft windows®2000, and the end of DLL Hell (English) and David D ' S of Rick Anderson Ouza, BJ Whalen and Peter Wilson's implementing Side-by-side Component sharing in Applications (Expanded) (English) are described in.. NET Box Many of the features provided by the rack are described in both articles, including application isolation and parallel components for applications built on the. NET platform. You will learn about the version support that is available on the. NET platform, which brings together local Windows applications more closely.
This article describes the concept of a compilation and describes how. NET uses compilations to troubleshoot versioning and publishing issues. We will discuss in particular how the assembly is built, how it is named, and how compilers and the common language runtime use compilations to record and enforce version dependencies between application fragments. We will also discuss how applications and administrators can customize version behavior through what we call version policy.
After the assembly is introduced and illustrated, several publishing scenarios are presented to give you some idea of the various packaging and distribution options available in the. NET framework.
From the customer's point of view, the most common version problem is what we call the DLL Hell problem. In short, DLL Hell refers to a series of problems that arise when multiple applications attempt to share a common component, such as a Dynamic Connection library (DLL) or a Component Object Model (COM) class. Most typically, an application will install a new version of the shared component that is not backward compatible with the existing version on the machine. Although the application you just installed is functioning correctly, an application that originally relied on the previous version of the shared component may no longer work. In some cases, the cause of the problem is more unpredictable. For example, when a user browses to some Web site, a Microsoft ActiveX® control is downloaded at the same time. If you download the control, it replaces any existing version of the control on the machine. If an application on the machine is using the control, it is likely that it will also stop working.
In many cases, it will take a long time for the user to discover that the application has stopped working. The result is often hard to remember when machine changes affected the application. The user may recall something that was installed a week ago, but the installation is not clearly associated with the state that is currently being seen. Worse still, there are few diagnostic tools available to help users (or help their technical support staff) determine what's wrong.
These problems are due to the fact that version information for different components of the application is not logged or enhanced by the system. Also, the changes that the system makes to an application affect all applications on the machine-now it is not easy to build an application that is completely isolated from change.
One reason for the difficulty of creating an isolated application is that the current run-time environment allows only individual versions of components or applications to be installed. This limitation means that the creator of the component must write their code in a backward-compatible manner, or else there is a risk of terminating an existing application when they install a new component. In fact, it's very difficult to write code that is always backwards compatible if possible. In. NET, the side by side concept is the core of the versioning problem. "Side by Side" is the ability to run different versions of the same component on the same machine at the same time. With support for parallel components, programmers do not have to work hard to maintain strict backward compatibility because different applications are free to use different versions of a shared component.
Publishing and installing
Installing the application now is a multi-step process. Generally, installing an application involves replicating many software components to disk, and a series of registry entries that describe those components in the system.
The separation of the keys in the registry and the file on the disk makes it very difficult to copy applications and uninstall them. Also, the relationship between many of the items required to fully describe a COM class in the registry is very loosely related. These items often include entries for union classes, interfaces, type libraries, and DCOM app IDs, and do not involve any items placed in the registry document extensions or component categories. Always keep these items synchronized manually.
Finally, the registration footprint is required to activate any COM class. This greatly complicates the process of publishing distributed applications because the appropriate registry entries must be made to each client's machine.
Another common problem now is that it is unrealistic to update a running application. This is the biggest problem with Web applications, and the Web application must stop working and restart to update the COM classes that the application uses.
These problems are mainly caused by component descriptions that are separated from the component itself. In other words, the application is not self-describing and independent.
The. NET framework must provide the following basic capabilities to solve the problem just described:
The application must be self-describing: The self-describing application removes dependency on the registry, enabling installation without impact and simple uninstall and replication.
Version information must be logged and enhanced: Version support must be built inside the platform to ensure that the appropriate version of the dependency is loaded at runtime.
You must remember the last known Good configuration: When the application runs successfully, the platform must provide the ability to remember the components that work together-including their versions.
Parallel components must be supported: allows multiple versions of components to be installed and run on the machine at the same time, allowing callers to specify the version they want to load instead of the unknowingly coerced version. The. NET framework allows a parallel neighbor to step forward by allowing multiple versions of the framework to exist simultaneously on a separate machine. This greatly simplifies the upgrade issue because administrators can choose to run different applications on different versions of the. NET Framework.
You must isolate the application: the. NET framework must simplify (and, in fact, default) write applications that are unaffected by changes in other applications on the machine.
A compilation is a building block used by the. NET framework to solve the version and issue of issues just described. A compilation is a publishing unit of types and resources. In many ways the assembly is the same as the current DLL. In essence, the assembly is a "logical DLL".
The assembly is self-describing from the metadata invocation manifest. Just as. NET uses metadata description types, it also uses metadata to describe the assembly of the containing type.
The assembly is not just about publishing. For example, the version in. NET is done at the assembly level-without any reduction, like a version of a module or type. Also, compilations are used to share code between applications. A assembly that contains a type is part of the type's flag.
The code that accesses the security system uses the assembly in the kernel of its licensing model. The author of the Assembly records a set of licenses that are required to run the code in the list, and the administrator authorizes the license to the assembly based code, which contains the code.
Finally, the Assembly is also the core of the type system and the Run-time system, in which they establish a visual boundary for the type and service as the running time range of the resolution reference type.
Compilation list
The list clearly includes the following relevant compilation data:
Identification: A compilation identity consists of three parts: name, version number, and option culture.
File list: The list includes a list of all the files that make up the assembly. For each file, the encryption information for its name and content is recorded when the manifest is created. This information is validated at run time to ensure consistency of the publishing unit.
Citation compilation: The relationship between the compilations is kept in the collection of compiled lists. Dependent information includes the version number, which is used to ensure that the correct version of the relationship is loaded at run time.
Output types and resources: visual options available for types and resources include "visual only in my assembly" and "visible to callers outside my assembly." ”
Licensing Requirements: Assembly licensing requirements are grouped into three groups: assembly run requirements, required but there are also some requirements for the Assembly, even unauthorized functionality, and the author does not want to compile the mandated requirements.
The IL disassembly (Ildasm) SDK tool is useful for viewing code and metadata in the assembly. Figure 1 is a list of examples with Ildasm reality. Assembly represents the compilation and. assembly extern contains information about other compilations.
Figure 1. List of examples shown in IL disassembly
Assembly structure
So far, the compilation is mainly described in terms of logical concepts. This section describes how they are physically embodied to help you make the assembly more specific.
Typically, the assembly consists of four elements: an assembly metadata (a manifest), a metadata description type, a media language (IL) code that implements that type, and a set of resources. Not all of these are present in each assembly. Only the checklist is strictly required, but the type or resource needs to be compiled with some important features.
There are several options for how these four elements can be packaged. For example, figure 2 represents the entire assembly: manifest, type metadata, IL code, and resources.
Figure 2. DLLs that contain all assembly elements
In another case, the content of one assembly may be split into multiple files. In Figure 3, the author chooses to detach some useful code into a different DLL and keep a large resource file in its original file (here is a JPEG file). One reason to do this is to optimize the download of the code. The. NET Framework downloads files only when they are referenced, so if the assembly contains code or resources that are frequently accessed, separating them into separate files will increase the efficiency of the download.
Figure 3. Assembly elements split into multiple files
DLL Hell A primary purpose is to share models that are currently used in component-based systems. By default, separate software components are shared by multiple applications on the machine. For example, each time an installer replicates a DLL to the system directory or registers a class in the COM registry, the code potentially affects other applications running on the machine. In fact, if an existing application uses the previous version of the shared component, the application will automatically use the new version. This is certainly better if the shared component is strictly backward-compatible, but it is difficult to maintain backward compatibility in many cases if it is not possible. If backward compatibility is not maintained or cannot be maintained, the side effects that are installed as other applications often cause application outages.
One of the principles of the. NET design policy is to isolate components (or assemblies). Isolating a compilation means that a compilation can only be accessed by one application-not shared by multiple applications on the machine and not likely to be affected by changes to the system by other applications. Isolation gives developers absolute control over the code used by the application. Isolation, or an application-specific assembly is expected to be default in. NET applications. The trend of isolating components has started with the introduction of. local files in Microsoft Windows 2000. This file is used to make the OS Loader and COM first lookup from the application directory when trying to locate the required components. (Refer to the documentation in the MSDN Library, implementing side-by-side Component sharing in applications.) ）
In some cases, however, it is necessary to share the assembly between applications. It is obvious that each application has its own copy of the system.winforms, system.asp, or public Web table control that is meaningless.
In. NET, it is a clear decision to share code between applications. Sharing a compilation requires some additional requirements. In particular, the shared assembler should support the same assembly side by version with multiple versions installed and running on the same machine, or even in the same process, at the same time. In addition, shared compilations have more stringent naming requirements. For example, a shared assembly must have a globally unique name.
The need for isolation and sharing leads us to consider two kinds of compilations. This is a fairly loose set, and there is no real structure between the two, but how they are used is different: dedicated to an application or shared with many applications.
Application-specific assembly
An application-specific assembly is a visual assembly that is visible only to an application. We expect this to be the most common scenario for. NET applications, because the. NET Framework helps build applications that are isolated from system changes caused by other applications.
The naming requirements for a private assembly are simple: The assembly name must be unique within the application. It is not necessary to have a globally unique name. Keeping names is not a problem because application developers have complete control over which assembly is isolated from the application.
Application-specific assemblies are deployed in the application directory structure where they are used. A private assembly can be placed directly in the application's directory or in its subdirectories. The common language runtime finds these compilations through a process called probing. "Probing" is a simple mapping between the assembly name and the file name that contains the manifest.
In particular, the universal language runtime records the name of the assembly in the assembly reference, appends ". dll" and looks up the file in the application's directory. There are variables in the scenario where the runtime accesses the compiled named subdirectory or the assembly-styled subdirectory. For example, a developer would choose to deploy a compilation of resources that contains a location in Germany to a subdirectory called "de" and deploy Spanish resources in a subdirectory called "es".
As mentioned earlier, each compilation list includes information about the version of its relationship. This version of the information is not enhanced for private compilation because the developer has complete control over the assembly deployed to the application directory.
Shared assembly
The. NET Framework also supports the concept of shared compilations. A shared assembly is used by multiple applications on a machine. Using. NET, sharing the code between applications is a clear decision. The shared assembly has some additional requirements for solving the shared problems we are experiencing now. In addition to supporting the juxtaposition previously described, there are many strict naming requirements for shared assemblies. For example, a shared assembly must have a globally unique name. And the system must provide "name protection"-more specifically, to prevent someone from using the writer's assembler name again. For example, suppose you are a manufacturer of a grid control and have published your assembly version 1. For writing you need to be sure that no one else can post a compilation or your grid control that claims to be version 2. The. NET Framework supports these naming requirements through technical support called share names. (Detailed in the next section).
In general, application writers do not have the same level of control over shared compilations used by applications. As a result, version information is checked each time the shared assembly is referenced. In addition, the. NET framework allows applications and administrators to overload the shared assembly version that applications use by specifying version policy.
Shared compilations are typically deployed to the Global Assembly library. A global assembler is a machine-wide assembly library for use by multiple applications. Using this library is not a requirement, but there are many advantages to doing so. For example, multiple versions of assembly-side storage are automatically provided. Also, administrators can use the library to deploy defect fixes or security patches that are used by applications on every machine they need. In this scenario, the configuration assembly to the global assembler storage can affect multiple applications on the machine. The. NET framework uses the concept of version policy (described later) to resolve issues that now appear in the shared area of the system, such as%windir%\system32.
Adding a compilation to a library requires explicit administrator action-in fact, the installation process must have administrator permissions. The assembly never ends at the end of the store as a side effect of running an application, nor is it any storage for a shared assembly that is currently working. In the Visual Studo. NET time frame, Windows installer will be updated to understand the assembly and assembly library. This means that you can use all of the features of Windows installer, such as selecting installation and application recovery using. NET applications.
The. NET SDK includes two tools for assembling libraries. The first is a tool called AL, which allows you to add compilations to the library. AL makes development and test scenarios easier, without creating an entire Windows installer package to add a compilation to the library. To add a compilation to a library using the/install switch:
Al/install:myassembly.dll
The second tool is the Windows Shell Extension, which allows you to use the Windows Explorer Operations Library. Figure 4 Represents a view of the global Assembler library.
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
