Sponsored Link •
Bill Venners: .NET Framework supports side-by-side execution, in which multiple versions of the .NET runtime can be used by different applications running at the same time. Isn't there a trade-off in side-by-side execution? What if I have twenty applications running, all using a different version of the same conceptual DLL, and maybe half of them would work with the most recent version. I guess memory is cheap these days, but...
Eric Gunnerson: It's a tradeoff between robustness and disk and memory use. What side-by-side execution says is that it's more important they get the version that the developer knew about and tested against than trying to save memory space and disk space.
Bruce Eckel: Is there also a way to migrate upwards? Say I'm writing for version 1.0 of the .NET Framework. Is there a way for me to say I expect my app will also work with version 2.0 of the Framework?
Eric Gunnerson: What we expect people to do is this: Say I write something and release it on version 1.0 of the Framework. Later, the version 2.0 of the Framework comes along. I can take my application and test it against version 2.0. If it works fine, I can change the configuration information that goes out with my application. I don't have to change the executable.
Dan Fernandez: Conversely, if your application is written to a particular version, you can say that particular version is required. In a config file, you can say, "This app can't work with anything less than 1.1."
Bill Venners: In theory, I like the idea of contracts. If new versions of a DLL adhere to the contract of the old version, my application should in theory still work with the new version. In practice, however, if I'm writing and delivering an application, I expect I'm just going to allow versions I've tested against. Why bother taking the risk that my application will break with new versions of the DLL?
Eric Gunnerson: The whole point here is to get away from having DLL Hell. DLL Hell was exactly that case where things worked a lot of times, but when they didn't work, you were just screwed. You just could not get out of it.
Bill Venners: So is this DLL Bliss now? What would you call it? DLL Heaven?
Eric Gunnerson: No, I wouldn't say it even comes close to that. One of the problems you have now is exactly what Bruce alluded to, how do you give people reasonable migration paths, so they can actually get new functionality without having to go back and recompile everything and change their config files? We have had a lot of discussions about that.
Bill Venners: Let's say I'm using your DLL. You come out with version 2.0. It has twice as much functionality. I wouldn't be calling that new functionality anyway, because it didn't exist when I wrote my application. So I have to write version 2.0 of my application, at which point I could compile and deploy against your 2.0 DLL. Why would I want to migrate my 1.0 application to your 2.0 DLL?
Eric Gunnerson: If you've written to DLL version 1.0, and in DLL version 2.0, the component you're using DLL was actually no different except for bug fixes, wouldn't you like to have those?
Bruce Eckel: Yes I would, unless I had adapted my code to the buggy previous version.
Come back Monday, February 16 for part III of a conversation with C++ creator Bjarne Stroustrup. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.
Eric Gunnerson is the author of A Programmer's Introduction to C# (Second Edition), which is available on Amazon.com at:
Eric Gunnerson's C# Compendium Weblog:
Dan Fernandez's Weblog:
You can find Eric Gunnerson's MSDN column, Working with C#, on this page:
Versioning, Compatibility, and Side-by-Side Execution in the .NET Framework:
Using the Microsoft .NET Framework to Create Windows-based Applications:
Private Communication Between Components in Assemblies:
What is a Microsoft Program Manager?:
ActiveWin.com's Interview with Eric Gunnerson:
.NET Books' Interview with Eric Gunnerson, Part I:
.NET Books' Interview with Eric Gunnerson, Part II: