Microsoft .Net Framework 2.0 Breaks Applications

The release of Beta 2 of Visual Studio 2005, code named Whidbey, which also introduces the .Net Framework 2.0, has raised some serious unintended backward compatibility issues.

At issue is the notion of breaking applications. Microsoft has identified situations where applications written to the .Net Framework 1.1 break when run against the .Net Framework 2.0.

Microsoft's compatibility goal for .Net Framework 1.1 applications is that they should work smoothly on the .Net Framework 2.0 except for a set of documented changes. But, this goal was significantly not achievable.

Thus, Microsoft is now calling the .Net developers to test their applications written in .Net Framework 1.1 against the latest .Net Framework 2.0. If there was any arising issue, please report it to the MSDN Product Feedback Center. Alternatively, .Net 1.1 applications can also be submitted for testing via e-mail to netfxcmp@microsoft.com.

Parallel with upgrading of framework version (or be it any programming environment), a set of breaking changes are almost non-escapable. Microsoft officials said that in the company's internal application compatibility testing, Microsoft testers found less than 10 breaking changes, including API breaking changes and behavior breaking changes.

Microsoft defined “Breaking Changes” as:

Breaking changes are changes in either the .Net Framework (runtime breaking changes) or Visual Studio (design/compile/project upgrade) that make certain application and development scenarios behave differently. These are not necessarily changes that we have found to be breaking an application; rather, these are changes in behavior discovered during design review and testing that could potentially impact an application.

An API breaking change is where the signature of a function changed or a function was removed; while behavior breaking change is involving changes in the behavior of a method, such as change of exception thrown and precision of floating point precision.

By default, an application built using the .Net Framework will run using the version of the Framework it was built against if that version is installed on the computer. In other words, stand-alone Windows client or Web applications built on the .Net Framework 1.1 will automatically run against that version even if the .Net Framework 2.0 is installed on the computer. However, managed add-ins to native applications, such as Microsoft Office or Internet Explorer, will automatically run against the latest version of the .Net Framework installed on the computer, unless configured otherwise.

Developers can run both .Net Framework 1.1 and .Net Framework 2.0 side by side on the same machine so that applications can run against the framework version they were built against, said Jay Roxe, the Microsoft's product manager for Visual Basic .Net.

When the application is started up on the .Net Framework 1.0, 1.1 or 2.0, the CLR (Common Language Runtime) looks at the .Net Framework version recorded in the application and tries to run the application on the version of the .Net Framework that the application was compiled with. If that version is not installed on the machine, the CLR will attempt to start the application on the latest .Net Framework and CLR, for example, an application compiled for .Net Framework 1.0 running on a machine with only .Net Framework 1.1 will be rolled forward to run on the .Net Framework 1.1. Likewise, an application compiled for .Net Framework 1.1 running on a machine with only the .Net Framework 2.0 will be rolled forward to run on the .Net Framework 2.0.

With reference to the above quoted statements, if the .Net Framework 1.1 application was rolled forward to run on .Net Framework 2.0, operations coded with the recorded breaking changes might failed. But, apparently, the goal for .Net Framework 1.1 applications to work smoothly on the .Net Framework 2.0 except for a set of documented changes, has failed in Beta testing stage.

Microsoft also pointed out two potential hot spots developers should look out for. The first involves serialization. "Any data serialized between versions of the .Net Framework is potentially fragile since serialization relies on the internal structure of the object," the white paper said. Also, applications that check for a particular version of the .Net Framework during setup could have problems, according to the white paper.

"We want to test any kind of application," Barak Cohen, the Business Development Manager for Microsoft's Visual Studio, said. "Different applications behave differently with regard to the framework. We want to get as large a sample as we can."

Cohen also added that "We're still shipping in the second half of 2005. There'll still be time. We still have time until the product ships."

References:
eWeek - Microsoft Recruits for .Net Framework Compatibility Testing
Microsoft - Microsoft .NET Framework 1.1 and 2.0 (Beta) Compatibility