.NET Reference Guide

Application Deployment — Versioning

Last updated Apr 29, 2005.

One of the primary causes of DLL Hell is the sharing model used in many component-based systems. By default, individual software components are shared by multiple applications on the machine. For example, every time an installation program copies a DLL to the system directory or registers a class in the COM registry, that code will potentially have an effect on other applications running on the machine. In particular, if an existing application used a previous version of that shared component, that application will automatically start using the new version. If the shared component is strictly backward compatible this may be okay, but in many cases maintaining backward compatibility is difficult or impossible. If backward compatibility is not maintained, this often results in applications that are broken as a side effect of other applications being installed. Microsoft recognized these problems and began moving toward isolated components with the introduction of the .local file in Windows 2000. The .local file is used to cause both the OS Loader and COM to look in the application directory first when trying to locate requested components.

The concept of isolated components is a principle design guideline in .NET. Isolating an assembly means that the assembly can only be accessed by one application—it is not shared by multiple applications on the machine and cannot be affected by changes made to the system by other applications. Isolation gives a developer absolute control over the code that is used by his application. Isolated, or application-private, assemblies are the default in .NET applications. However, there are cases where sharing an assembly between applications is necessary. For example, it clearly wouldn't make sense for every application to carry its own copy of System.Windowns.Forms, System.Web or a common Web Forms control.

In .NET, sharing code between applications is an explicit decision. Assemblies that are shared have some additional requirements. Specifically, shared assemblies should support side by side execution so multiple versions of the same assembly can be installed and run on the same machine, or even within the same process, at the same time. In addition, shared assemblies have stricter naming requirements. For example, an assembly that is shared must have a name that is globally unique.

The need for both isolation and sharing leads us to think of two "kinds" of assemblies. This is a rather loose categorization in that there are no real structural differences between the two, but rather the difference is in how they will be used: whether private to one application or shared among many.