Home | Shorter Path | About Me
Home
About Me
RSS Feed

Planners (you know you want it)

Archive

2004

01

02

03

04

05

06

07

08

09

10

11

12

 

2005

01

02

03

04

05

06

07

08

09

10

11

12

 

2006

01

02

03

04

05

06

07

08

09

10

11

12


Blogroll
 
Borland
Allen Bauer
Anders Ohlsson
Chris Bensen
Malcolm Groves
Michael Swindell
Steve Trefethen
Borland Blogs
TeamB
TeamB Blog Server
Nick Hodges
Other
Algorithms for the Masses
Brad Abrams
Chris Brumme
Chris Pratley
Dan Miser
Don Box
Falafel Flogs
iunknown.com
Joel on Software
Matt Pietrek
Suzanne Cook
The Daily WTF
The New Old Thing
Wintellog

.NET's own private DLL hell

Wednesday, February 25, 2004 12:33 PM

Microsoft's solution to the "DLL hell" issue in .NET, at least for shared DLLs, is using strong-named assemblies. When you're binding your application to a string-named assembly, you're actually binding to a specific version of that assembly. If the user installs another version of that assembly, your application would still use the version you've specified. This means you can be sure no one will break your application by upgrading third-party assemblies. At least in theory.

The .NET framework assemblies themselves (those that ship as part of the framework) may or may not follow these rules. .NET 1.1 assemblies, for example, are unified, which means that if an application requests a .NET 1.0 assembly it might actually get a .NET 1.1 assembly. The assembly version is not selected by the application, but by the CLR. If the application was loaded by .NET 1.1's CLR, and requests a 1.0 assembly, what it actually gets is a 1.1 assembly. This is called Assembly Binding Redirection.

You can modify the redirection rules by writing a configuration file for your application and assemblies. Configuration files let you specify exactly what version should be used by each assembly. A configuration file that redirects a 1.1 application to use 1.0 assemblies is quite a beast.

Then there's the whole issue of publisher policies. A publisher policy is a way for a publisher to tell applications that one version of an assembly is compatible with another version, and should be used instead. So even if your application binds to the strong-named MyAssembly.dll 2.0.0.0, if the publisher says MyAssembly.dll 2.0.1.5 is compatible, your application will use that instead. Unless, of course, the system administrator chooses to edit the configuration file for an application and disable publisher policies, by adding the following element:

<publisherPolicy apply="no"/>

Kind of like the rule for leap years (you know, a year is a leap year if it is divisible by 4, excpet if it is divisible by 100, only years divisible by 400 are still leap years), but with an evil twist.

|

Copyright 2004 Yorai Aminov