DLL Hell
DLLs gave developers the ability to create function libraries and programs that could
be shared with more than one application. Windows itself was based on DLLs. While
the advantages of shared code modules expanded developer opportunities, it also
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.
Metadata
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
o Identity (name, version, culture, public key).
o The types that are exported.
o Other assemblies that this assembly depends on.
o Security permissions needed to run
• Description of types
o Name, visibility, base class, and interfaces implemented.
o Members (methods, fields, properties, events, nested types)
• Attributes
o Additional descriptive elements that modify types and members
Advantages of Metadata:
Now let us see the advantages of Metadata:
Self describing files:
CLR modules and assemblies are self-describing. Module's metadata contains
everything needed to interact with another module. Metadata automatically provides
the functionality of Interface Definition Language (IDL) in COM, allowing you to use
one file for both definition and implementation. Runtime modules and assemblies do
not even require registration with the operating system. As a result, the descriptions
used by the runtime always reflect the actual code in your compiled file, which
increases application reliability.
Language Interoperability and easier component-based design:
Metadata provides all the information required about compiled code for you to inherit
a class from a PE file written in a different language. You can create an instance of
any class written in any managed language (any language that targets the Common
Language Runtime) without worrying about explicit marshaling or using custom
interoperability code.
Attributes:
The .NET Framework allows you to declare specific kinds of metadata, called
attributes, in your compiled file. Attributes can be found throughout the .NET
Framework and are used to control in more detail how your program behaves at run
time. Additionally, you can emit your own custom metadata into .NET Framework
files through user-defined custom attributes.
Assembly
Assemblies are the building blocks of .NET Framework applications; they form the
fundamental unit of deployment, version control, reuse, activation scoping, and
security permissions. An assembly is a collection of types and resources that are
built to work together and form a logical unit of functionality. An assembly provides
the common language runtime with the information it needs to be aware of type
implementations. To the runtime, a type does not exist outside the context of an
assembly.
An assembly does the following functions:
• It contains the code that the runtime executes.
• It forms a security boundary. An assembly is the unit at which permissions are
requested and granted.
• It forms a type boundary. Every type’s identity includes the name of the
assembly at which it resides.
• It forms a reference scope boundary. The assembly's manifest contains assembly
metadata that is used for resolving types and satisfying resource requests. It
specifies the types and resources that are exposed outside the assembly.
• It forms a version boundary. The assembly is the smallest version able unit in the
common language runtime; all types and resources in the same assembly are
versioned as a unit.
• It forms a deployment unit. When an application starts, only the assemblies the
application initially calls must be present. Other assemblies, such as localization
resources or assemblies containing utility classes, can be retrieved on demand.
This allows applications to be kept simple and thin when first downloaded.
• It is a unit where side-by-side execution is supported.
Contents of an Assembly
• Assembly Manifest
• Assembly Name
• Version Information
• Types
• Locale
• Cryptographic Hash
• Security Permissions
Assembly Manifest
Every assembly, whether static or dynamic, contains a collection of data that
describes how the elements in the assembly relate to each other. The assembly
manifest contains this assembly metadata. An assembly manifest contains the
following details:
• Identity. An assembly's identity consists of three parts: a name, a version
number, and an optional culture.
• File list. A manifest includes a list of all files that make up the assembly.
• Referenced assemblies. Dependencies between assemblies are stored in the
calling assembly's manifest. The dependency information includes a version
number, which is used at run time to ensure that the correct version of the
dependency is loaded.
• Exported types and resources. The visibility options available to types and
resources include "visible only within my assembly" and "visible to callers outside
my assembly."
• Permission requests. The permission requests for an assembly are grouped into
three sets: 1) those required for the assembly to run, 2) those that are desired
but the assembly will still have some functionality even if they aren't granted,
and 3) those that the author never wants the assembly to be granted.
DLLs gave developers the ability to create function libraries and programs that could
be shared with more than one application. Windows itself was based on DLLs. While
the advantages of shared code modules expanded developer opportunities, it also
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.
Metadata
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
o Identity (name, version, culture, public key).
o The types that are exported.
o Other assemblies that this assembly depends on.
o Security permissions needed to run
• Description of types
o Name, visibility, base class, and interfaces implemented.
o Members (methods, fields, properties, events, nested types)
• Attributes
o Additional descriptive elements that modify types and members
Advantages of Metadata:
Now let us see the advantages of Metadata:
Self describing files:
CLR modules and assemblies are self-describing. Module's metadata contains
everything needed to interact with another module. Metadata automatically provides
the functionality of Interface Definition Language (IDL) in COM, allowing you to use
one file for both definition and implementation. Runtime modules and assemblies do
not even require registration with the operating system. As a result, the descriptions
used by the runtime always reflect the actual code in your compiled file, which
increases application reliability.
Language Interoperability and easier component-based design:
Metadata provides all the information required about compiled code for you to inherit
a class from a PE file written in a different language. You can create an instance of
any class written in any managed language (any language that targets the Common
Language Runtime) without worrying about explicit marshaling or using custom
interoperability code.
Attributes:
The .NET Framework allows you to declare specific kinds of metadata, called
attributes, in your compiled file. Attributes can be found throughout the .NET
Framework and are used to control in more detail how your program behaves at run
time. Additionally, you can emit your own custom metadata into .NET Framework
files through user-defined custom attributes.
Assembly
Assemblies are the building blocks of .NET Framework applications; they form the
fundamental unit of deployment, version control, reuse, activation scoping, and
security permissions. An assembly is a collection of types and resources that are
built to work together and form a logical unit of functionality. An assembly provides
the common language runtime with the information it needs to be aware of type
implementations. To the runtime, a type does not exist outside the context of an
assembly.
An assembly does the following functions:
• It contains the code that the runtime executes.
• It forms a security boundary. An assembly is the unit at which permissions are
requested and granted.
• It forms a type boundary. Every type’s identity includes the name of the
assembly at which it resides.
• It forms a reference scope boundary. The assembly's manifest contains assembly
metadata that is used for resolving types and satisfying resource requests. It
specifies the types and resources that are exposed outside the assembly.
• It forms a version boundary. The assembly is the smallest version able unit in the
common language runtime; all types and resources in the same assembly are
versioned as a unit.
• It forms a deployment unit. When an application starts, only the assemblies the
application initially calls must be present. Other assemblies, such as localization
resources or assemblies containing utility classes, can be retrieved on demand.
This allows applications to be kept simple and thin when first downloaded.
• It is a unit where side-by-side execution is supported.
Contents of an Assembly
• Assembly Manifest
• Assembly Name
• Version Information
• Types
• Locale
• Cryptographic Hash
• Security Permissions
Assembly Manifest
Every assembly, whether static or dynamic, contains a collection of data that
describes how the elements in the assembly relate to each other. The assembly
manifest contains this assembly metadata. An assembly manifest contains the
following details:
• Identity. An assembly's identity consists of three parts: a name, a version
number, and an optional culture.
• File list. A manifest includes a list of all files that make up the assembly.
• Referenced assemblies. Dependencies between assemblies are stored in the
calling assembly's manifest. The dependency information includes a version
number, which is used at run time to ensure that the correct version of the
dependency is loaded.
• Exported types and resources. The visibility options available to types and
resources include "visible only within my assembly" and "visible to callers outside
my assembly."
• Permission requests. The permission requests for an assembly are grouped into
three sets: 1) those required for the assembly to run, 2) those that are desired
but the assembly will still have some functionality even if they aren't granted,
and 3) those that the author never wants the assembly to be granted.
No comments:
Post a Comment