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."
In my mind, Microsoft is fighting a losing battle here. Try as they might to stay ahead of breaking changes and compatibility problems, Microsoft correctly recognizes that they’ll miss some things.
But the cost for things Microsoft will miss is going to be astoundingly high. Organizations that encounter breaking changes to their functional .NET 4.0 apps when they push an in-place update to .NET 4.5 won’t feel like they’re some isolated edge case. Currently, it looks like Microsoft will ask people who bump into problems with .NET 4.0 and 4.5 versioning to file a bug report on Connect—something so pathetic and laughable that I can’t fathom it (my hatred of Connect knows no bounds). But even when astute developers sidetrack the nightmare of Connect and who go to Microsoft support directly for a hot-fix, there’s still going to be the specter of downtime and an additional sense of loss of trust and confidence by management in the .NET Framework and in Microsoft.
Consequently, as the costs associated with failure are so incredibly high in terms of the potential for negative impact on perceptions about the value of the .NET Framework, I can’t help but wonder what makes Microsoft think that an in-place update would make more sense than a side-by-side rollout. Are they worried about those extra configuration steps necessary for managing two different versions of the .NET Framework? If so, that’s a moot point, because like it or not, there are patently going to be two different versions of the .NET Framework—and that can’t be swept under the rug.
Looking at this from the outside (and contemplating the potential horror stories and what this will do to the .NET landscape), I can’t see what makes an in-place update a more enviable approach than a side-by-side rollout.
No, I’m Spartacus!
The second big problem I see is that the .NET Framework 4.5 will have the exact same version as .NET 4.0. As stated by Microsoft, "One of the first things you’ll notice about .NET 4.5 is the version number (4.0.30319) is the same as .NET 4; this is the practice used by other in-place updates."
Frankly, this is just asinine. Yes, keeping the version the same works for minor bug fixes. But it patently will not work for a major release that adds and modifies APIs and introduces breaking changes.
Even if I’m wrong about the desire and need for a side-by-side rollout of .NET 4.5 (alongside 4.0), no one with a brain welcomes the idea of .NET 4.5 assemblies and interfaces being stealthily put into place under some sort of scheme that lets two distinctly different sets of APIs and underlying behaviors both claim that they’re the exact same version—down to even the build number.
Without a doubt, this is going to cause problems, distrust, and malaise among systems admins, who will rightly complain to management and who will have to jump through all sorts of hoops to meet application and development needs within their organizations—to say nothing of the headache that this approach will also cause developers.
For example, I see two scenarios that are going to be extremely problematic. First is the simple case in which developers perform due-diligence and fully test their .NET 4.5 applications before deployment and then need target and host machines patched to .NET 4.5 to enjoy new features and benefits. Initially, it shouldn’t be too hard for IT to upgrade or patch servers or workstations as needed with the .NET 4.5 Framework. But if machines somehow get missed, the specter of .NET 4.5 apps being deployed to machines that only have the .NET 4.0 version of 4.0.30319 will no doubt cause confusion and pain. Seriously, how does Microsoft expect that IT admins or developers won’t shake their heads when they find out that target boxes are running .NET 4.0 versions of the .NET Framework 4.0.30319 instead of .NET 4.5 versions of the .NET Framework 4.0.30319—the prospect is laughable at best (and sounds like a comedy routine to just say or type).
Second, imagine cases in which developers have found or determined that breaking changes in .NET 4.5 are things they can’t risk or afford. How do IT and developers work in unison to prevent .NET 4.5 versions of the .NET Framework 4.0.30319 from being installed on top of .NET 4.0 versions of the .NET Framework 4.0.30319? Again, just saying this out loud or typing it is beyond ridiculous and will cause problems for Microsoft and the .NET Framework in terms of trust and confidence by folks out in the trenches.
Conclusion
I’d really like Microsoft to make the case for why this set of upcoming additions, changes, and breaking behaviors wouldn’t be better served by means of a side-by-side approach instead of an in-place update, because I honestly realize I might be overlooking a key consideration somewhere. However, I'm confident that there’s a huge potential risk here for businesses and organizations to be burned by breaking changes via in-place updates to .NET 4.5.
On the other hand, the idea of .NET 4.5 masquerading as a lock, stock, and barrel duplicate of the .NET Framework 4.0 is absurd. There’s no way that this makes sense. It will cause all sorts of confusion and problems in .config files, diagnostics, installers, and organizations where developers need to explicitly target either the .NET Framework 4.0 or the .NET Framework 4.5. So I’m hoping that Microsoft addresses this particular problem before it becomes a complete train wreck.
