By June’s ‘Black Tuesday’ patches to Windows’ .Net Framework library have admins hopping mad — again
Why can’t Microsoft turn out decent patches for its sprawling .Net Framework? That’s what I — and about a million admins all over the world — want to know.
Best Comptia A+ Training, Comptia A+ Certification at Certkingdom.com
Last month’s Black Tuesday .Net patches, MS11-039 and MS11-044, set new lows, even for Microsoft, even for .Net patches. There’s a list of known problems with MS11-044, documented in KB 2538814, that’s as long as your arm. As long as Michael Jordan’s arm, for that matter — and those are just the problems Microsoft has fessed up to.
Susan Bradley updates a lot of different Windows systems and, as a Microsoft MVP for Small Business Server, catches a lot of flak from other admins who are trying to keep their boxes running. She puts it succinctly: “I think Microsoft ought to be ashamed of how difficult it is to keep .Net updated. I don’t come to this conclusion lightly.”
Indeed — in the past year, Microsoft has published seven Security Bulletins for .Net Framework 3.5 or 4 (MS10-041, MS10-060, MS10-070, MS10-077, MS11-028, MS11-039, and MS11-044). Most of the Security Bulletins have at least a handful of acknowledged, documented problems. MS11-028 was withdrawn and re-issued. MS10-077 was re-issued with a “detection change”; in other words, the installer didn’t work right; Microsoft pulled the patch and then posted a different version. MS10-070 was pulled and re-issued; the documentation is now up to version 4.1 and counting. MS10-041 was pulled, re-issued, then pulled and re-issued again. You get the picture.
Why is it so incredibly difficult to issue reliable patches for .Net?
For starters, .Net isn’t a nice, neat bundle. It’s a spread-out mess of issued, updated, and redacted components. In many cases, admins have to keep old versions around because new versions can break old apps. It isn’t unusual to find Windows PCs running three or more different copies of .Net Framework. I’ve seen versions 1.1, 2.0 SP 1, 2.0 SP 2, 3.0, 3.0 SP 2, 3.5, 3.5 SP 1, 4 Client, and 4 Full on fairly recent machines.
My production machine is currently running .Net Framework 2.0 SP 2, 3.0 SP 2, 3.5 SP 1, 4 Client, and 4 Full. That’s five different versions of .Net, all installed on the same Windows 7 PC. I don’t dare remove any of them manually, for fear of breaking an application that relies on a specific version.
One of the problems is so common — receiving a Windows Update error code 0x643 or Windows Installer error code 1603 — that Microsoft points people to a single Knowledge Base article that describes how to dislodge the automatic update mechanism and try again. The Knowledge Base article says the trick works with .Net 1.0, 1.1, 2.0, 3.0, and 3.5. One can only wonder why it took Microsoft so long to fix the faulty installer logic.
Ultimately, the problem stems from the fact that .Net is more like an operating system within an operating system — a collection of sometimes-conflicting libraries and protocols that have evolved significantly over the past 10 years, with hooks deep into every nook and cranny of every Windows version. Still, if Microsoft can produce somewhat reliable patches to the Windows kernel, why does it keep dropping the ball with .Net?
While many of us wonder how Microsoft will support .Net in Windows 8 (see Joab Jackson’s analysis in Developer_World), experienced admins also question how in the world Microsoft will patch it. Immersive apps with the new Windows Division-written CLR sure sound nice, but who’s going to keep the bloody thing working?
Curious about which versions of .Net are running on your computers? Download and run the .Net Framework Setup Verification Utility, no installation necessary. The drop-down box lists all of the detected versions.
No Comment