With the .NET Framework metadata technology, installing applications is as easy as copying them into a directory. The .NET Framework is even capable of self-healing when applications are damaged.
Application deployment is greatly simplified with the .NET Framework. One of the largest challenges faced by developers and administrators (and ultimately users) is versioning. If your system works fine today, and then you install a new application and suddenly nothing works any more, it’s very often because the new application overwrote some shared library and (more often than not) fixed some bug that existing applications were relying on.
The .NET Framework includes a couple of advances that virtually eliminate DLL version conflicts. First, it includes a very strong internal naming system that makes it much harder for two libraries that may even have the same file name to be mistaken for each other. Beyond that, there’s a new side-by-side deployment feature. If that new application really does overwrite a shared library, the existing application can actually repair itself. The next time the existing application starts up, it will check all its shared files. If it finds that one has changed and that the changes are incompatible, it can ask the runtime to fetch a version it knows it can work with.
Side-by-side deployment is enabled by assemblies and manifests.
What Is an Assembly?
An assembly is the primary building block of a .NET application. It is a collection of functionality built, versioned, and deployed as a single implementation unit (one or multiple files). All managed types and resources are marked either as assessable only within their implementation unit or as exported for use by code outside that unit.
Assemblies are self-describing through their manifest, an integral part of every assembly.
What Does the Manifest Do?
The manifest performs the following functions:
Establishes the assembly identity, in the form of a text name, version, culture, and if the assembly is to be shared across applications, a digital signature.
Defines what files (by name and file hash) make up the assembly implementation.
Itemizes the compile-time dependencies on other assemblies.
Specifies the types and resources that make up the assembly, including which ones are exported from the assembly.
Specifies the set of permissions required for this assembly to run properly.
This information is used at run time to resolve references, enforce version binding policy, and validate the integrity of loaded assemblies. The runtime can determine and locate the assembly for any running object, since every type is loaded in the context of an assembly. Assemblies are also the unit at which code access security permissions are applied. The identity evidence for each assembly is considered separately when determining what permissions to grant the code it contains.
Put simply, assemblies contain information about the dependencies of the things inside. The runtime is responsible for making sure these dependencies are fulfilled, including fetching necessary components from approved sites (a technique that uses the.NET Framework security system).
Because the runtime is responsible for actually managing applications as they run, the .NET Framework is even able to run two versions of the same component side by side. The self-describing nature of assemblies also helps makes zero-impact install and no-touch deployment feasible.
It has always been possible for multiple copies of a software component to reside on the same system. In the past, however, only one of these copies can be registered with the operating system or loaded for execution, because the policy for locating and loading components is global to the system. Through side-by-side deployment, the .NET Framework adds the infrastructure necessary to support per-application policies that govern the locating and loading of components.
Application configuration information defines where to look for assemblies, thus the runtime can load different versions of the same assembly for two different applications that are running concurrently. This eliminates issues that arise from incompatibilities between component versions, improving overall system stability. If necessary, administrators can add configuration information, such as a different versioning policy, to assemblies at deployment time, but the original information provided at build time is never lost.
Because assemblies are self-describing, no explicit registration with the operating system is required. Application deployment can be as simple as copying files to a directory tree. Configuration information is stored in XML files that can be edited by any text editor.
The .NET Framework includes technologies to make applications more reliable. For example, memory, threads, and processes are managed by the .NET Framework to ensure that memory leaks don’t occur. ASP.NET monitors running Web applications and can automatically restart them at administrator-defined intervals. Many of the reliability features in the .NET Framework come from the application services supplied by the unified classes called Enterprise Services (System.EnterpriseServices). Using the same engine as COM+, these application services provide such features as transactions, messaging, events, partitions, and object request broker.
Typical Web application running ASP versus ASP.NET; both on the same computer running Windows 2000 and SQL Server 2000. he .NET Framework improves the performance of typical Web applications. ASP.NET includes advanced compilation and caching features that improve performance by a factor of two to three over existing Active Server Pages applications.