introduced the problem of updates, revisions, and usage. If one program relied on a
specific version of a DLL, and another program upgraded that same DLL, the first
program quite often stopped working.
Microsoft added to the problem with upgrades of some system DLLs, like comctl.dll,
the library used to get file, font, color and printing dialog boxes. If things weren't
bad enough with version clashes, if you wanted to uninstall an application, you could
easily delete a DLL that was still being used by another program.
Recognizing the problem, Microsoft incorporated the ability to track usage of DLLs
with the Registry starting formally with Windows 95, and allowed only one version of
a DLL to run in memory at a time. Adding yet another complication, when a new
application was installed that used an existing DLL, it would increment a usage
counter. On uninstall, the counter would be decremented and if no application was
using the DLL, it could be deleted.
That was, in theory. Over the history of Windows, the method of tracking of DLL
usage was changed by Microsoft several times, as well as the problem of rogue
installations that didn't play by the rules--the result was called "DLL HELL", and the
user was the victim.
Solving DLL hell is one thing that the .NET Framework and the CLR targeted. Under
the .NET Framework, you can now have multiple versions of a DLL running
concurrently. This allows developers to ship a version that works with their program
and not worry about stepping on another program. The way .NET does this is to
discontinue using the registry to tie DLLs to applications and by introducing the
concept of an assembly.
On the .NET Platform, if you want to install an application in the clients place all you
have to do is use XCopy which copies all the necessary program files to a directory
on the client’s computer. And while uninstalling all you have to do is just delete the
directory containing the application and your application is uninstalled.
An Assembly is a logical DLL and consists of one or more scripts, DLLs, or
executables, and a manifest (a collection of metadata in XML format describing how
assembly elements relate). Metadata stored within the Assembly, is Microsoft's
solution to the registry problem. On the .NET Platform programs are compiled into
.NET PE (Portable Executable) files. The header section of every .NET PE file contains
a special new section for Metadata (This means Metadata for every PE files is
contained within the PE file itself thus abolishing the need for any separate registry
entries). Metadata is nothing but a description of every namespace, class, method,
property etc. contained within the PE file. Through Metadata you can discover all the
classes and their members contained within the PE file.
Metadata describes every type and member defined in your code in a Multilanguage
form. Metadata stores the following information:
Description of the assembly
Identity (name, version, culture, public key).
The types that are exported.
Other assemblies that this assembly depends on.