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 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.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
