Sounds pretty good. However, I guess the problem is you can not change the class loader implementation of WebSphere or other commercial stuff :(
Oliver On Fri, 17 Dec 2004 23:16:42 +0000, Chris Lambrou <[EMAIL PROTECTED]> wrote: > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
