Web Forefront

Scenario: Your developing an application that relies on a set of utilities, call them Utilities.dll. All is fine until its necessary to update some of the functionality in Utilities.dll to support a newer part of the application.

Since some part of your application has relied on Utilities.dll or even other applications might have relied on its functionality, you are left with a few options. Re-test everything to ensure the new Utilities.dll version does not break any functionality (modifying any dependent applications accordingly) or simply leave both the old Utilties.dll and the newer Utilties.dll to co-exist.

The last option is the easiest, having the capacity to leverage both a Utilities.dll 1.0 and 2.0 version, which is a functionality that needs to be offered by the run-time environment. In .NET 1.0 this was one of the primary features to address the issue of 'DLL Hell'

The 'Hell' moniker is due to how Windows applications ( and actually all applications) load dependencies. In the pre-.NET world, if an application required something like Utilities.dll, there had better be just one Utilities.dll in the entire system or you would otherwise incur in hell not knowing which Utilities.dll was loaded by an application. Which is something Java still faces, its run-time is incapable of enforcing run-time versioning (See OSGi: Versioning and Java's run-time )

The way this is solved in .NET is by adding meta-data to the DLL file or assembly (See Assembly Versioning ). Which is to say, its not the actual code that is versioned but the package which contains the code. A process that is strikingly similar to Java's OSGi approach of adding meta-data to a JARs MANIFEST.MF file to support run-time versioning.

In this manner, the .NET run-time is capable of managing different DLL versions and granting access on a case by case basis, something which is currently missing in Java. Currently, Java's run-time is only capable of supporting this via OSGi. Will OSGi eventually form part of Java's run-time? Well, even as the planning phases for Java 7 are being announced, its not clear if OSGi -- or something similar -- will materialize by this seventh release, something which has been supported in .NET since its first.