Skip to main content

DLL Hell Solution...Demistified


DLL Hell…Solved in .Net Framework


Before NET Framework, DLL conflicts occurred because applications could not distinguish between incompatible versions of the same code. Type information contained in a DLL was bound only to a file name. An application failed to know if the types contained in a DLL were the same types as contained in existing application. Hence, a new version would overwrite an older version and break applications.

.Net Framework introduced the Concept of Side-By-Side Execution to overcome this problem.
This model introduced some vital changes in naming conventions of Dll and brought in the concept of versioning, wherein a new version of component/application can run with existing version, without any conflict.

Side-by-side execution Features:

Strong-named assemblies.

Side-by-side execution uses strong-named assemblies to bind type information to a specific version of an assembly. This prevents an application or component from binding to an invalid version of an assembly. Strong-named assemblies also allow multiple versions of a file to exist on the same computer and to be used by applications.


Version-aware code storage.

The .NET Framework provides version-aware code storage in the global assembly cache(GAC). The global assembly cache is a computer-wide code cache present on all computers with the .NET Framework installed. It stores assemblies based on version, culture, and publisher information, and supports multiple versions of components and applications.


Isolation. 

Using the .NET Framework, you can create applications and components that execute in isolation. Isolation here means using  resources and sharing them with other versions of an application or component. Isolation also includes storing files in a version-specific way.


Runtime Version Information

When an application is compiled, information regarding the version of runtime (CLR), which it requires to run, is stored in two locations.

  1. Managed Executables: Stores information on the runtime version used to compile application/Component.

  1. Application Configuration File: Stores information about Runtime version that the application or component requires at


Runtime Version Information in the Managed Executable

The portable executable (PE) file header (Please go through the assemblies to know more about PE) of each managed application and component contains information about the runtime version it was built with.

It is this info that CLR uses to determine which version of runtime it needs to load for running the application/component.


 Runtime Version Information in the Application Configuration File



Another alternative to PE headers is the usage of Application Configuration files
to provide runtime version information. The application configuration file is an XML-based file, created and stored with the application,
This file can specify which versions of the runtime and which versions of a component the application supports.
This file  can also be used to test an application's compatibility with different versions of the runtime.


 

.NET Framework Assembly (How it works)

The .NET Framework consists of a version of the CLR and .NET Framework assemblies that make up the type library.

These .NET Framework assemblies are treated by the runtime as a single unit.

For example, version 1.0 of the .NET Framework consists of the runtime version 1.0.3705 and .NET Framework assemblies version 1.0.3300.0.

By default, the runtime loads only those .NET Framework assemblies that belong to the runtime version that is loaded in a process.

When an application is launched, all references to types in code run by the runtime are directed to .NET Framework assemblies with the same version number as the runtime that is loaded in a process.

This prevents the runtime from loading assemblies from different versions of the .NET Framework unless the runtime is specifically instructed to do so.

    

Assembly Unification and Components

The application determines which version of the runtime it uses. The unification process includes any components an application may use. An application can redirect a component it uses to run with a particular version of the runtime. Components compiled with one version of the runtime could be redirected to use another version.




Assembly unification can redirect assembly binding


Applications can override this default behavior by providing binding redirection information in the application configuration file for any assembly.

These overrides redirect the runtime to use a specific version of a .NET Framework assembly without affecting how other .NET Framework assemblies are loaded. 





Load Specific Runtime Version(How to determine)

The CLR uses the following information to determine which version of the runtime to load for an application:

The runtime versions those are available.
The runtime versions that an application supports.

The runtime uses the application configuration file and the portable executable (PE) file header to determine which version of the runtime an application supports.

 If no application configuration file is present, the runtime loads the runtime version specified in the application's PE file header (if that version is available).

If an application configuration file is present, the runtime determines the appropriate runtime version to load .


<How CLR determines which Version to LOAD
The Application Configuration File contains Element (multiple allowed), which specifies the runtime version used by application/component.

Generally, a single runtime  info suffices  in element , However if multiple the supported runtime versions  are specified, , the runtime loads the runtime version specified by the first element.

 If any of the specified versions is not available, the runtime examines the next element and attempts to load the runtime version
If none of the specified versions, is available, a message is displayed to the user.

 The runtime reads the PE file header of the application's executable file.
 If the specified runtime in the PE file header is available, the runtime loads it. If the runtime version is not available, the runtime searches for a runtime version determined by Microsoft to be compatible with the runtime version in the PE header. If Failed to find any version, Error Message to the User.


This Article was intended for some base know-how of Assemly loading and CLR versioning management.
Soon I'll post code implementing the theoretical aspects discussed here.

Till Next Time...Happy Coding





Labels:

Comments

Post a Comment

Popular posts from this blog

Asp.Net 4.0: An Overview-Part-III

This is the last post in the series which will explore the following new features of ASP.Net 4.0  Performance Monitoring for Individual Applications in a Single Worker Process Web.config File Refactoring Permanently Redirecting a Page Expanding the Range of Allowable URLs Performance Monitoring for Individual Applications in a Single Worker Process It is a common practice to host multiple ASP.NET applications in a single worker process, In order to increase the number of Web sites that can be hosted on a single server. This practice results in difficulties for server administrators to identify an individual application that is experiencing problems. ASP.NET 4 introduces new resource-monitoring functionality introduced by the CLR. To enable this functionality, following XML configuration snippet is added to the aspnet.config configuration file.(This file is located in the directory where the .NET Framework is installed ) <?xml version="1.0" encoding="UTF-8"
Post a Comment
Read more

WCF-REST Services-Part-II

HOW REST is implemented in WCF Part-I of the series explored the REST conceptually and this post will explore how REST is implemented in WCF. For REST implementation in WCF, 2 new attributes namely WebGetAttribute and WebInvokeAttribute are introduced in WCF along with a URI template mechanism that enables you to declare the URI and verb to which each method is going to respond. The infrastructure comes in the form of a binding ( WebHttpBinding ) and a behavior ( WebHttpBehavior ) that provide the correct networking stack for using REST. Also, there is some hosting infrastructure help from a custom Service¬Host ( WebServiceHost ) and a ServiceHostFactory ( WebServiceHostFactory ). How WCF Routes messages WCF routes network messages to methods on instances of the classes defined as implementations of the service. Default behavior ( Dispatching ) for WCF is to do this routing based on the concept of action. For this dispatching to work, an action needs to be present in ev
Post a Comment
Read more

SOLID principles -Code Samples and Free Ebook

I planned to write code samples for SOLID principle implementations, however I am a firm believer of " NOT RE-INVENTING THE WHEEL ", when all you need is use the wheels and make a new CAR. Going by the ideology, I have found an excellent  SOLID principles FREE -Ebook ( covering all aspects of SOLID design principles, with Code sample). This book is an excellent visual aid to remember these principles, as it uses Motivational posters for explaining SOLID design principles. One additional advantage to the above mentioned book is the Code-Refactoring ebook . Both of these books can be downloaded from this EBOOK download Link Both of these books can be downloaded form here. Hope this book proves useful... Till next we connect.... Happy Learning..
Post a Comment
Read more