Problem solve Get help with specific problems with your technologies, process and projects.

Breaking Changes in .NET Framework 2.0

MSDN's Breaking Changes page lets developers see what may work differently, or not at all, when an application moves from .NET 1.x to 2.0. Ed Tittel explains how this will affect developers and offers a few examples of breaking changes.

When it comes to upgrading older VS.NET applications from earlier version of the .NET Framework -- that is, from 1.0 or 1.1 to 2.0 -- developers are always concerned to know what's to worry about as they make the switch. The MSDN Breaking Changes Web page documents changes to the .NET Framework (called Run-Time Breaking Changes), or Visual Studio's design, compile and project upgrade functionality (called Design-Time Breaking Changes), which can cause application and development scenarios to act differently in the 2.0 version from the 1.0 and 1.1 versions.

This doesn't mean the changes will actually break an application (though most of the runtime items will do just that); it simply means they will cause changes in behavior during design review and testing that could potentially impact an application. Lest you grow overly concerned about this, the latest word from Microsoft is that less than 30 such items have been documented to date.

Breaking changes occur for a variety of reason that range from standards compliance, responses to customer feedback and functionality requests, and accuracy or correctness. Here's an example of the kinds of things you'll find documented in the two sets of breaking changes we point to in the preceding paragraph.

  • Standards compliance (run-time): the ISO tag for the Kyrgyz Republic (aka Kyrgyzstan) in System.Globalization was changed from KZ to KG.
  • Customer feedback (run-time): The ASP.NET project model was updated to remove the V1 model for view links, because no known Control vendors used the API, and because it was poorly documented.
  • Accuracy (run-time): Numeric precision for floating point values was increased in certain cases, partly because the CLI specification already indicated this change was possible.
  • Microsoft.Office APIs (design-time): The extensibility library removed its reference to Microsoft.Office.dll and switched to Microsoft.VisualStudio.CommandBars.dll, to remove dependencies on this no-longer needed dll. Any add-ins or macros that call that dll must be updated to use the new dll instead.
  • V1.1 Controls with a non-Boolean AutoSize property throws an exception when used in V2.0 designer (design-time): The .NET framework now uses a Boolean AutoSize property in its Control, so third-party non-Boolean AutoSize property causes an invalid cast exception. The name or type of the third-party property must be changed to avoid this exception.
  • XslTransform throw InvalidOperationException in V2.0, XsltException in V1.1 (design-time): If the user calls Execute on a transform class without loading a stylesheet, this results in an InvalidOperation Exception in V2.0, but an XsltException was thrown in V1.1. This is a genuine design error that must be corrected to avoid either exception.

    Browsing around the Design-Time and Run-Time Breaking Changes pages will therefore help developers figure out what's different about the environment that they must rework or repair when migrating V1.0 or V1.1 applications to V2.0 of the .NET Framework. Definitely worth a visit to anyone facing that situation!

    Ed Tittel is a writer and trainer whose interests include XML and development topics, along with IT Certification and information security. E-mail with comments, questions, or suggested topics or tools to review. Cool tools rule!

  • Dig Deeper on .NET Framework security best practices

    Start the conversation

    Send me notifications when other members comment.

    Please create a username to comment.