Microsoft is currently in the process of bundling a large number of improvements, additions, and changes to the .NET Framework in the form of .NET Framework 4.5. As presently planned, .NET 4.5 won’t run side-by-side with .NET 4.0; instead it will overwrite and transparently replace .NET 4.0 as an in-place update. As I see it, there are a number of serious problems and concerns with this approach, and I’m hoping Microsoft will reconsider a side-by-side rollout.
The .NET Framework Is More Than Just Code
It’s easy to complain about things from the outside. I get that. I also get that a huge number of people at Microsoft are working hard to meet developer and business needs for new features and capabilities that will provide great benefit.
By the same token, IT organizations are becoming increasingly skeptical of all the various incarnations of the .NET Framework and its various patches and service packs—simply because systems administrators have sadly bumped into too many mishaps where a versioning change has burned them in terms of lost productivity, functionality, or uptime. Stated differently, as great as the .NET Framework is for developers, the platform’s capabilities are limited when .NET Framework adoption is restricted by IT managers and businesses’ concerns of stability and confidence due to versioning and compatibility problems.
Consequently, when it comes to versioning Microsoft needs to remember that there’s much more than potential developer pain that needs to be addressed. There’s also a question of perception among businesses and IT organizations that don’t like hearing from developers that a recent change to the .NET Framework has busted existing applications or solutions. And frankly, developers don’t like having to tell clients about these problems either—because it makes them look bad as well.
Accordingly, I’ve got two major concerns about the intended rollout of .NET 4.5 as an in-place replacement for .NET 4.0.Both of them strike me as places where developers will potentially feel pain and it will be negatively reflected back on Microsoft and the .NET Framework.
A Losing Battle on Backward Compatibility
As defined by Microsoft in a blog post detailing the compatibility of the .NET Framework 4.5, it’s obvious that .NET 4.5 will introduce breaking changes.
Obviously, breaking changes are part and parcel to development. They’re just a fact of life. That’s not what worries me. What worries me is the fact that if the .NET Framework 4.5 is deployed as an in-place update,, then there’s going to be breaking changes that wouldn’t have occurred had .NET 4.5 been deployed as a side-by-side version of the .NET Framework.
Granted, a new side-by-side version of the the .NET Framework would be a major undertaking. And it wouldn’t be painless, because it would require additional juggling between versions after deployment. But the way I see it is that if IT organizations and developers need to install .NET 4.5 binaries to take advantage of new functionality, why not push those binaries into a new side-by-side version of the .NET Framework? Yes, that might take more time to install and deploy, and yes, there’d be concern about running .NET 4.0 apps accidentally as .NET 4.5 apps (or vice-versa, where I assume they’d instantly crash).
But there wouldn’t be the potential horror for needing .NET 4.5 binaries for one project, installing the .NET 4.5 update, and then watching other, existing, .NET 4.0 apps break. This is something that Microsoft clearly recognizes can and will happen, as described in the “Compatibility of .NET Framework 4.5”:
"Our primary concern is guaranteeing applications you use do not break after you install .NET 4.5. We accomplish this by running hundreds of application in our compatibility lab to find issues as soon as they’re introduced. While designing new features or changing existing code, we keep compatibility in mind. And a small group of us, the Developer Division Compatibility Council (DDCC), monitor changes made by developers. We review potential breaking changes, and help teams understand and assess the compatibility impact of new features and bug fixes. For .NET 4.5, members of DDCC reviewed every proposed breaking change, every new feature, and a majority of the bug fixes for the release.
We’ve put a lot of effort into maintaining a consistently high bar for compatibility across the product, yet we know some issues may get past us. Many applications will exercise the .NET Framework in ways that we did not expect or we lack test coverage for. Still we care about knowing every issue, even those that may seem like corner cases."