At 12:30 AM 1/24/2007, Keith J. Farmer wrote (in part) >There should be a better means for cooperation between third party apps and >the runtime as regards version. I don't make the claim that it's an easy >problem to solve, but the solution shouldn't be at odds with the native >support, nor should it put a burden on the end-user. > >My ideal, for example, would be to have IronPython-on-Windows included as a >component via Microsoft Update, and serviced through those channels. This >would mean, then, that IronPython apps would have to be safe against >revisions. Perhaps under Vista.
If IronPython were installed in the GAC, new versions would lie side-by-side with old ones. A "publisher policy file" could be provided with the new version that tells the CLR that the new version is (supposed to be) 100% compatible with (some subset of existing) old versions, so that apps compiled against the older version will use the new version without needing to be recompiled. If the publisher policy file doesn't indicate complete compatibility, existing apps continue to use the version with which they were compiled. This prevents the "version N of DLL X was installed in system32, overwriting version M, because app B requires version N; this breaks app A that only works with version M of X" variant of DLL hell. If the developer (or user) of an app determines that the new version of IP will in fact work with the app without it being recompiled, she can put an instruction to load the newer DLL in the app.exe.config file. Similarly, if it turns out that the compatibility promised by the publisher policy file is not realized, the developer (or user) of the app can force the app to use the original version with which the app was compiled. This leaves the decision about whether to risk blindly using a new version without the component publisher's official sanction can be made by app developers (or users), and the decision can be changed easily (by modifying the app.exe.config file). This is the solution to DLL hell that .Net promises. It only works for apps compiled against components that are installed in the GAC. It works very well for professional component-builders (DevExpress, Infragistics, ComponentOne, etc) as they are able to deliver a new version along with an assertion that it is completely compatible (the publisher policy file) and all apps compiled against the old version will start using it. If they deliver a new version that they realize is not 100% compatible, they can indicate that as well -- existing apps will continue to work with the old version, newly built apps work with the new version, and the app developer (or user) can try out the new version with an existing app without recompiling and back out if there's trouble. This relatively wonderful scenario (at least compared to pre-.Net DLL hell) cannot be realized without the GAC, as it is only with components that are in the GAC (or in the framework itself) that different versions live "side by side" in a central location about which the CLR has full knowledge. If you develop a component and are unwilling to make the promises that are involved with GAC installation, the easiest and least-hellish solution is to put your component in the directory with the EXE (or in a subdirectory that the runtime will look in). This lets each app decide whether to continue to use the old version, or to use the new version without recompiling (risking a problem if the new version isn't completely compatible), and of course at any point the developers of the app can recompile with (and deliver) the new version. It is a sign of the relative immaturity of IronPython that its developers (correctly IMO) are not willing to do the extra work involved in installing in the GAC. Someday, IP will be in the GAC (or part of the framework). J. Merrill / Analytical Software Corp _______________________________________________ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
