Sponsored Link •
Anders Hejlsberg, the lead C# architect, talks with Bruce Eckel and Bill Venners about DLL hell and interface contracts, strong names, and the importance of interoperability.
Anders Hejlsberg, a distinguished engineer at Microsoft, led the team that designed the C# (pronounced C Sharp) programming language. Hejlsberg first vaulted onto the software world stage in the early eighties by creating a Pascal compiler for MS-DOS and CP/M. A very young company called Borland soon hired Hejlsberg and bought his compiler, which was thereafter marketed as Turbo Pascal. At Borland, Hejlsberg continued to develop Turbo Pascal and eventually led the team that designed Turbo Pascal's replacement: Delphi. In 1996, after 13 years with Borland, Hejlsberg joined Microsoft, where he initially worked as an architect of Visual J++ and the Windows Foundation Classes (WFC). Subsequently, Hejlsberg was chief designer of C# and a key participant in the creation of the .NET framework. Currently, Anders Hejlsberg leads the continued development of the C# programming language.
On July 30, 2003, Bruce Eckel, author of Thinking in C++ and Thinking in Java, and Bill Venners, editor-in-chief of Artima.com, met with Anders Hejlsberg in his office at Microsoft in Redmond, Washington. In this interview, which will be published in multiple installments on Artima.com and on an audio CD-ROM to be released this fall by Bruce Eckel, Anders Hejlsberg discusses many design choices of the C# language and the .NET framework.
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.
Versioning is all about relaxing the rules in the right way and introducing leeway. The absolute answer, the only way guaranteed to not break anything, is to change nothing. It is therefore important to support side-by-side execution of multiple versions of the same functionality, on the same box or even in the same process. Side-by-side execution is one option we support in .NET that we didn't support in the older DLL model.