Correct me if I'm wrong, but didn't Microsoft come up with some type of solution to DLL hell in Windows 2000 or XP? I seem to recall reading that a long time ago, but I'm not a Windows programmer, so I have no idea. Does anyone else know?
The .NET equivalent of a jar file is called an assembly. For libraries, this is basically a DLL. Every time the code is compiled, the DLL is automatically allocated a unique version number. When you compile your code that refers to code in a library assembly, your assembly has an explicit dependency on that library assembly. At runtime, when your code tries to invoke the library code, an exception will be raised if the exact version of the library assembly is not available.
It would appear that if there are bug fixes or other improvements to the library, and a recompiled assembly DLL is substituted for the one you originally compiled against, then your code will break. At runtime, your code will fail to link to the library code, since the version number no longer matches. Obviously, a maintenance release of a library component shouldn't require a recompilation and redeployment of all software that uses the library, so .NET provides a mechanism for you to explicitly define a version number. This allows you to provide updated library components to users without requiring them to recompile. However, this only works if you don't break backwards compatibility.
If you break backwards compatibility in a library, then you have to change the version number. However, .NET still allows you to deploy different, incompatible versions of the same DLL. When you deploy the application, your installer has to register both versions of the DLL with the GAC - the Global Assembly Cache. In this way, if you have a complex application that contains two components that rely on incompatible versions of the same library DLL, the VM instantiates two separate versions of the library DLL, and links the two components to the appropriate instance.
One possible Java analogy to this would be to bundle all code inside jar archives. Each jar contains dependency information, perhaps stored in the manifest, or some other meta-file, that describes the jar's own name and version number, and a list of the names and version numbers of its dependencies. A suitable class loader can then use this meta information to stitch the classes together appropriately. Actually, my knowledge of java class loaders isn't sufficient for me to assert that this solution would definitely work, but it's a start, and I hope all of this serves to illustrate how .NET allows multiple versions of the same library to coexist.
Chris
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
