Microsoft is having compatability issues with the upcoming .Net Framework 2.0, but says the problem will not delay the release of the Visual Studio 2005 toolset planned for later this year.
Applications built on .Net Framework 1.1 have been breaking, or changing behavior, on version 2.0, according to the company"s white paper.
The document said the company desires to have .Net Framework 1.1 applications work smoothly on .Net 2.0 with the exception of a set of documented changes. "During the beta 2 release, we have not yet achieved this goal and are seeking feedback on issues that can be addressed before the release of the .Net Framework 2.0," the white paper states.
In its application compatibility testing, Microsoft found fewer than 10 changes in .Net Framework or Visual Studio that have been found to affect an application, the white paper said.
Breaking changes were made for reasons such as standards compliance, customer feedback, and correctness, Microsoft said. The company believes many of the changes will affect very few users.
The company also states: "On occasions where application code built against the .Net Framework 1.1 is loaded by the .Net Framework 2.0 and encounters a breaking change, the application may fail."
Microsoft, however, will have time to address the issues in order to ship the release of the Visual Studio 2005 platform, also known as "Whidbey," as planned in the second half of 2005, according to Jaye Roxe, product manager for Visual Basic .Net. .Net Framework 2.0 will be supported in the Whidbey platform and in Windows operating systems.
The framework provides an underlying platform for running "managed" applications in which basic programming chores such as memory allocations are taken care of. Version 2.0 is to feature improvements in performance as well as enhancements for Windows Forms and ASP.Net operations.
Microsoft is working to ensure that .Net Framework 1.1 applications run on version 2.0, said Roxe. Changes in 2.0 were made in response to customer feedback, he said.
"What you"re seeing in this white paper is our description of the types of changes that we [made], how this could potentially impact an application and any changes that we think could be made to the code," Roxe said.
Breaks could be caused by factors such as changing how a user would call a method, Roxe said.
A Microsoft ISV downplayed the issue. "We didn"t see very many issues at all," said Steve Dadoly, director of development at Infragistics, which makes a toolset for extending the .Net Framework. "There were some code members that were depreciated from [.Net Framework 1.1] to 2.0, but the compiler warned us of those and we just had to change to a different method. The code compiled and ran for the most part."
Well-known potential "hotspots" for compatibility include serialization, in which data serialized between versions of the Framework is potentially fragile, because serialization relies on the internal structure of the object. Microsoft is investing in version-tolerant serialization, to be available when Visual Studio 2005 and .Net Framework 2.0 ship.
The other hotspot is checking for a particular version of the .Net Framework. Applications that check for a specific version of the framework during setup or check for a specific version while running are "version-brittle."
Roxe emphasized that applications inherently know when they have been built on versions 1.1 or 2.0 of the framework, meaning the applications will natively try to run on the version they were built against.
"What that means is developers can continue to rely on the functionality that they"ve had from the .Net Framework 1.1, even if they install the .Net Framework 2.0 on the machine," Roxe said.