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

Covariance and Contravariance-General Discussion

If you have just started the exploration of .Net Framework 4.0, two terms namely Covariance and Contravariance might have been heard. The concept that these terms encapsulate are used by most developer almost daily, however there has never been any botheration about the terminologies. Now, what actually these terms mean and how are these going to affect us as a developer, if we dive in to the details. The simple answer is it’s always good to know your tools before actually using them. Enough philosophy, let’s get to the business. Starting the discussion let me reiterate that in addition to Covariance and Contravariance, there is another terminology, Invariance. I’ll by start here by diving into the details of Invariance and then proceed further. Invariance: Invariance can be better understood by considering the types in .Net.>net has basically two type, value-types and reference-types. Value types (int, double etc) are invariant i.e. the types can’t be interchanged either ...
1 comment
Read more

Advanced WCF

In this post, I am sharing the link of articles about  advanced topics in WCF. The List of articles is exhaustive and can serve as your repository for all WCF queries. Concurrency,Throttling & Callbacks  WCF Concurrency (Single, Multiple and Re entrant) and Throttling   WCF-Interop and BinarySecurityToken  WCF Callbacks  Creating Web Services From WSDL Link1 Link2 Link3 Link4 WCF-Security WCF over HTTPS   Transport Security(basic)/HTTPS UserNamePasswordValidator ServerCertificateValidationCallback 9 simple steps to enable X.509 certificates on WCF - CodeProject http://www.codeproject.com/KB/WCF/9StepsWCF.aspx?display=Print Message Security(Certificate)/PeerTrust Securing WCF Services with Certificates. - CodeProject http://www.codeproject.com/KB/WCF/wcf_certificates.aspx Message Security(Certificate)/ChainTrust How To Configure WCF Security Using Only X.509 Certificates - CodePr...
Post a Comment
Read more