.NET Framework 2.0 breaks: The sky is (not really) falling |
 |
By Mike Gunderloy
03 Jun 2005 | SearchVB.com |
|
|
A week or two back Microsoft released some information on compatibility between the .NET Framework 1.1 and the current beta version of the .NET Framework 2.0. This document uses scary words like "breaking changes" and was seized on immediately by some parts of the computer press as an excuse to write headlines along the lines of ".NET 2.0 Breaks Existing Applications." It's always easy to go for the cheap shot against Microsoft, especially when you're on a deadline. But the real story is a good deal more interesting - and better for developers.
First, if you actually read the document, you'll find that there are only a few edge cases where an existing 1.1 application can actually fail due to a 2.0 breaking change. The most important of these is that if a 1.1 application is run on a computer with only the 2.0 Framework installed, it will run with the 2.0 Framework. The easy mitigation: make sure you install the 1.1 Framework with your 1.1 application, and configure the application to request the 1.1 Framework, which avoids the problem in all cases.
So, the time to be concerned is when you're migrating 1.1 code to 2.0. If you're a smart developer -- and you are, right? -- you're not going to migrate without testing your code. In this case, Microsoft's publication of the list of changes helps you, by giving you a list of things to look for. In fact, it's an incredibly detailed list; there's an entire help file you can download that exhaustively details every breaking change of which the team is aware, no matter how trivial.
As a random example, here's one breaking change from the System.Windows.Forms namespace: "In previous versions of the Framework, when a user set up a form with a RadioButton group and no radio button was selected, the first radio button in the group would become selected. Now, an item is only selected if the user presses the space bar or one of the arrow keys when focus is in the radio button group. The .NET Framework 2.0 behavior now matches that of standard Windows dialogs and Web pages." There are not likely to be many applications out there that depend on the (non-standard) behavior of the .NET 1.1 Framework in this area. But armed with the list of changes, it's pretty easy to inspect all of the radio button groups on your application and to take corrective action if yours is one of them.
Most of the breaking changes are of a similarly trivial level. There are some for which there's no way to get back to the previous behavior: these are generally corrections to conform with external standards (The ISO tag in System.Globalization for Kyrgyzstan was updated from KZ to KY) or fixes to security holes in the Framework where the previous behavior was dangerous. But for the most part, the story here is this: the .NET team has gone out of their way to make your life easier if you're a developer upgrading a .NET 1.1 application to run on .NET 2.0. The increased transparency we've seen throughout the .NET 2.0 beta cycle is being translated into continued transparency as the product nears release, with practical guidance from Microsoft on all aspects of .NET development. And rather than a dastardly plan to break applications, that's actually a good thing.
Mike Gunderloy is an independent developer and author working in eastern Washington state. His recent books include Painless Project Management with FogBugz (Apress) and Coder to Developer (Sybex). You can read more of Mike's work at his Larkware Web site, or contact him at MikeG1@larkfarm.com.
|
|
|
|
