To what extent is “DLL Hell” a failure of interface contracts to work adequately in practice?

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at:, or follow me on Twitter.

(Tonight I’m dumping some of my notes onto my blog. Not sure why I kept these for years without publishing. I was probably waiting for a moment when I could write a longer essay about them.)

Bill Venners: To what extent is “DLL Hell” a failure of interface contracts to work adequately in practice? If everyone fully understands and adheres to the contract of the functions of a particular DLL, shouldn’t updating that DLL in theory not break any code?

Anders Hejlsberg: Hell has many tortures. One aspect of DLL hell is that you don’t adhere to your promised semantic contract. You do something different than what you did before, and therefore you break code. That’s actually probably not the biggest issue that we face. The true problem with DLL hell is that we don’t allow you to have multiple different versions of a particular DLL present on the machine. Once you upgrade the DLL you upgrade everybody, and that’s a mighty big hammer.

Bill Venners: But if the contract is followed, shouldn’t the most recent version work for all users of that DLL?

Anders Hejlsberg: In theory, yes. But any change is potentially a breaking change. Even a bug fix could break code if someone has relied on the bug. By the strictest definition you realize that you can do nothing once you’ve shipped.

Bruce Eckel: Have you come up with any interesting thoughts about ways to enforce semantic contracts?

Anders Hejlsberg: I think the most promising ideas are existing and new developments in pre- and post-conditions, assertions, invariants, and so forth. Microsoft research has several ongoing projects that we continually evaluate . We have looked at some pretty concrete proposals. In the end we realized that—as is the case for almost any truly important feature—you can’t just do contract enforcement from purely a programming language perspective. You have to push it into the infrastructure, the CLR, the Common Language Specification, and therefore all the other programming languages. What good is putting invariants on an interface, if it is optional for the implementer of the interface to include the code of the invariant? So it’s really more at a type system level than at a programming language level, but that doesn’t necessarily mean that we’re not going to address it. We are not doing that in the next release, but it could become a first class feature in C# down the line.