Welcome to Multiple Version Hell
DLL Hell is largely a thing of the past with VS.NET and the .NET Framework. But having multiple versions of the same components can be trying in its own right.
Welcome to Multiple Version Hell
by Jonathan Goodyear
Posted March 26, 2004
|
Jonathan Goodyear |
One of the most notable benefits of .NET development is that it effectively ends the concept of DLL Hell. Side-by-side execution works well, and you can demonstrate it on a grand scale by installing multiple versions of the .NET Framework on one computer. All is right with the world; well, unless you're a .NET consultant.
My company's clients pay by the hour, so I steer clear of the wasteful "not created here" syndrome. If I can fulfill a client's need in half the time by using a third-party tool or component, that's exactly what I do. It helps that there are some great companies building powerful .NET products out there. Unfortunately, many third-party vendors are taking advantage of the fact that their components can run side-by-side and are releasing new product versions far too often.
At any one time, I have multiple clients at various stages in their development life cycle. The accelerated release schedule of third-party vendors means that many of these customers are using different versions of the same component, based on when they decided to purchase it. It's nice that the components run side-by-side on my development laptop, but some of these components have install packages that are hundreds of megabytes in size. This can add up quickly.
Why don't I just upgrade each of my clients to the most recent version? For one, many components are not absolutely backwards compatible. An unnamed vendor produces a menu control that renders slightly differently with each version. That slight rendering difference can have a big impact on precise Web page layouts. That takes time (and money) to fix. Also, upgrades to newer component versions aren't always free, and it doesn't make sense for a consultant to force his clients to pay for an upgrade. My problems should not be my clients' problems.
Visual Studio .NET complicates things further. Some component vendors never imagined that you might want to use different versions of the same component in the same Web application (I won't go into the details, but it happened to me). Consequently, they don't change the assembly filenames when they increment product versions, as some (more astute) vendors do. Visual Studio .NET won't let you have a reference to two different versions of the same library because this creates a file collision in the Web application's /bin folder. If you move to using version binding in the Global Assembly Cache, you lose the advantage of XCopy deployment.
I have aged 10 years trying to get multiple versions of multiple components on multiple projects to work with each other, thanks to the "paint yourself into a corner" design decisions made by numerous third-party vendors. I'm not sure what's worse: knowing something can't be done, or knowing it can be done but you have to move heaven and earth to do it.
Multiple Version Hell isn't exclusive to .NET components, either. I use a well-known commercial tool built in .NET to manage my source code. Most of my clients use the same tool. It works famously, but suffers from the fact that a new version is released every couple of months. The version of the repository must match the version of the client application, so I ran into the problem of not being able to connect to some of my clients' source-code repositories that had newer installations of the tool.
The upgrade path is relatively seamless, but what happens if your clients can't (or don't want to) upgrade just yet? Thankfully, this particular application has a command-line switch on the client installation that allows multiple versions to coexist on the same machine. I have three versions of the application installed on my laptop. The redundancy is maddening.
Things have gotten better if you look at the big picture. With .NET, we've moved from an age of "it can't be done" to "it can be done, but you're not going to like it" with regards to product versioning. I fear, though, that an age of redundancy is upon us. It's a good thing that hard drives these days are cheaper and have more space. We're going to need it.
About the Author
Jonathan Goodyear is the president of ASPSOFT Inc., a consulting firm based in Orlando, Fla. He's a Microsoft Certified Solution Developer (MCSD) and the author of Debugging ASP.NET (New Riders). Jonathan is also a contributing editor for Visual Studio Magazine and is a Microsoft MVP. Reach him at [email protected] or through his angryCoder eZine.