. NET Framework solves the DLL Hell problem: Problem Description

. NET Framework and DLL Hell problems: Version Problems

From the customer's perspective, the most common version issue is what we call the DLL Hell issue. To put it simply, DLL Hell refers to a class when multiple applications try to share a public component, such as a dynamic Connection Library DLL) or a component object model COM) 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 the problem is.

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.

. NET Framework and DLL Hell: 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.

The above section briefly describes the DLL Hell problem that needs to be solved by the. NET Framework.

1. ASP. net mvc unit test: confusing the Path attribute of the HttpContext class
2. Custom ControllerFactory: interface implementation, supporting Area
3. ASP. NET Routing
4. Add custom routes for ASP. net mvc applications
5. Learning how to use ASP. net mvc Routing