AlbertPacino
Explorer
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.
The issues arose with the release of Beta 2 of Visual Studio 2005, also known as Whidbey, which Microsoft released last month. Beta 2 introduces the .Net Framework 2.0.
During internal testing, Microsoft became aware of the breaking changes and Tuesday posted a white paper to address some of the specifics of what causes applications to break. However, Microsoft is looking for more applications to test. The company is looking for .Net Framework 1.1 applications to test and is asking developers to submit their applications by sending an e-mail to netfxcmp@microsoft.com.
Microsoft defines breaking changes as "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."
So Microsoft recommends that developers test their .Net Framework 1.1 applications against .Net Framework 2.0 during the Beta 2 phase of the Whidbey rollout. The final version of Whidbey is slated for release in the second half of this year.
Microsoft officials said 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. And 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.
However, according to the Microsoft white paper on the compatibility issues, "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." Yet, "During the Beta 2 release, we have not yet achieved this goal and are seeking feedback on application issues that can be addressed before the release of the .Net Framework 2.0."
For its part, 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. The API breaking changes were made due to security concerns, and behavior breaking changes might occur due to factors like a change in the precision of floating-point operations, the company said.
Indeed, overall, breaking changes in the .Net Framework 2.0 were related to standards compliance, customer feedback and correctness, the company said.
"Compatibility is always important to Microsoft," said Barak Cohen, business development manager for Microsoft's Visual Studio. "The changes in Whidbey are a direct response to customer requests. We are acting on our wish to make a product work best for our customers."
Jay Roxe, Microsoft's product manager for Visual Basic .Net, said that 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. And in instances where a .Net Framework 1.1-based application is loaded by .Net Framework 2.0 and runs into a breaking change, "the application may fail," the Microsoft compatibility white paper said.
However, 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, Roxe said.
"By default when you build an application against the .Net Framework it will default to the version you built it on," Roxe said. "If you have 2.0 on your machine and the application is written against 1.1, it will by default try to run on 1.1."
Moreover, according to the Microsoft white paper: "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."
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.
Meanwhile, Microsoft said it will consider "reverting breaking changes" prior to the release of the final version of.Net Framework 2.0, "if they are found to impact applications."
Asked if Microsoft still has time to address the problems that might arise through the compatibility testing the company is asking users to assist with, Cohen said: "We're still shipping in the second half of 2005. There'll still be time. We still have time until the product ships."
Meanwhile, Jesse Kaplan, program manager in the Visual Studio CLR team, said the lessons learned from the testing "we're not planning to use just for Whidbey," but Microsoft will use them in other development initiatives.
Moreover, in the white paper Microsoft suggests various methods for avoiding or mitigating any compatibility issues. One is to test .Net Framework 1.1-based applications against .Net Framework 2.0 and make necessary changes to the application. A second method is to distribute .Net Framework 1.1 with their applications, and a third is simply to upgrade all applications to .Net Framework 2.0, the company said.
"We want to test any kind of application," Cohen said. "Different applications behave differently with regard to the framework. We want to get as large a sample as we can."
Added Roxe: "We're bringing applications in-house and testing them against the 2.0 framework, and we're still looking for people to send us additional apps for testing compatibility."
One ISV that has worked with Microsoft to test its application against .Net Framework 2.0 is Infragistics Inc., of East Windsor, N.J.
"Microsoft is actively working with its customers on all levels to make the transition from the 1.1 framework to the 2.0 framework happen as smoothly as possible," said Steve Dadoly, Infragistics' director of development.
Dadoly said although Microsoft has its work cut out for it, he thinks the software giant is up to the task.
"Due to the countless ways developers can build unique applications on the .Net Framework, it is virtually impossible for Microsoft and the ISV community to account for all of the possible scenarios customers may go through when upgrading an application," Dadoly said. "What Microsoft is doing for customers and ISVs like ourselves throughout the beta cycle for Visual Studio 2005 [with .Net Framework 2.0] is opening the line of communication for us to express any issues or concerns their customers may have and then responding to these concerns by either working hand-in-hand to help resolve the issue or simply sending a fix in a timely fashion.
"When it specifically came to releasing a beta version of our NetAdvantage tool set for developing user interfaces for Windows Forms, ASP.Net and Tablet PC applications that was compatible with the recent beta of .Net 2.0, Microsoft played a key role in testing the tools to overcome any bugs we faced throughout our development cycle," he said. "This enabled us to make our beta available to our customers immediately after they received the latest .Net Framework 2.0 beta."
In addition, Dadoly said Infragistics recently upgraded about 1.8 million lines of presentation layer source code from .Net Framework 1.0 to .Net Framework 2.0 as part of the company's effort to release the beta version of its NetAdvantage.
But not everybody was as generous as Dadoly. Said one developer familiar with breaking changes related to the rollout of Windows XP SP2, who asked not to be identified: "For Microsoft to issue a white paper like this, applications must be breaking all over the place."
However, SP2 was said to have up to 50 breaking changes and Microsoft officials said they could only identify fewer than 10 for the .Net Framework 2.0.
The Microsoft white paper can be found here
Source
