Developers are taking in stride Microsoft's disclosure that it is encountering compatibility problems with its next-gen .Net Framework.

Microsoft's shout-out to developers, requesting they do more testing of the .Net Framework before the Redmond software vendor delivers that technology to market, doesn't seem to be fazing the Microsoft development community.

The .Net Framework is Microsoft's software-platform alternative to Java. It is a collection of technologies, including ASP.Net, the Common Language Runtime and various class libraries, that can be used to build and run Windows applications. Microsoft is planning to make the 2.0 release part of Visual Studio 2005, due to ship later this year, and include the .Net 2.0 code along with Longhorn.

Microsoft disclosed on Wednesday that some applications written to the .Net Framework 1.1 break when run against the .Net Framework 2.0.

But after digesting Microsoft's new white papers on the subject, developers said they weren't surprised by Microsoft's acknowledgement.

"When a consumer-oriented software upgrade breaks something, it's a disaster by all accounts. However, .NET framework is a developer-oriented software, and we developers expect that some things will get broken with an upgrade," said one Windows developer, who requested anonymity.

"There is a Russian idiom that says: 'While cutting a tree, wood chips fly.' To put it in context, progress requires change, and effects of the change are not always painless," the developer continued. "In the developer's world, breaking changes are a fact of life. I doubt that anyone but a complete novice in the development world expects a seamless transition to a new version of their framework, whether it's Microsoft.NET or Symbian. However, changes must be justified in the minds of developers."

Developers said they believed they could guarantee application compatibility with the next-gen .Net Framework by making some fairly simple tweaks to their applications.

"The port won't be hard," said Joel Spolsky, CEO and founder of Fog Creek Software. "It's not nearly as bad as the port from VB 6.0 to VB.Net 1.0. From the list I saw, it doesn't look much worse than any other compiler upgrade. Developers know that when they upgrade their compiler they are going to have to spend a week or two making small changes to get their code working again."

Spolsky added that the Microsoft-identified "breaking changes" that result from moving to .Net 1.1 to .Net 2.0 "are not really that big a deal, because developers can continue to target the .Net 1.1 runtime, even if their users upgrade, for as long as they need to until they have had a chance to port their application to .Net 2.0."

"This backward incompatibility isn't really a problem for end users. In fact, it's more of a problem for developers looking to port their .NET 1.1 code to .NET 2.0," said Ryan Hoffman, owner of the Extended64.com Web site, which follows 64-bit Windows technology developments. "But, if they are developers, they shouldn't have a problem making the minor tweaks required to run."

Hoffman said it only took him about an hour to port the Bink.nu and Extended64.com websites to .NET 2.0 from .Net 1.1. He said he was required to make approximately 20-30 minor changes out of thousands of lines of code.

Robert McLaws — president of Interscape Technologies, as well as a Microsoft ASP.NET Most Valuable Professional — concurred.

"Compatibility is a very interesting problem. Microsoft is the compatibility king, and I think it always has been. It's hard to improve software and keep old code working at the same time.

"There were a few issues with compatibility in the transition between 1.0 and 1.1, and that is to be expected here too," McLaws continued. "I think there were something like 20 or 30 breaking changes between 1.0 and 1.1, so I think this is an improvement. Side-by-side execution makes this a small deal. Most people will have .NET 1.1 and .NET 2.0 installed together, at least for a while during the transition."

In spite of developers' confidence that the move from 1.1 to 2.0 should be trivial, one Microsoft analyst said there still could be some hiccups on the .Net upgrade road.

"ISVs (independent software vendors) shipping applications that require the .NET Framework must make sure to redistribute the precise version of the Framework that they have built and tested against and not just assume that the 'latest version' is already installed and that it will work," cautioned Greg DeMichillie, a senior analyst with Directions on Microsoft, Kirkland, Wash.

DiMichillie added: "Of course, redistributing OS components presents its own challenges. The biggest one is making sure you are distributing an appropriately patched component, otherwise you run the risk of installing a component with a security vulnerability in it."

He cited as an example of this the Microsoft GDI+ vulnerability "that affected all kinds of third-party applications that Microsoft wasn't even able to enumerate."

With each release of the .Net Framework, developer expectations are raised, pointed out the aforementioned anonymous developer.

"The first release of the .NET framework, Microsoft had made a much better investment into the popularization of the concept that this is indeed not VB7, not COM+, but a whole new, better, bigger, faster ballgame. That is why the fact that the code base was completely incompatible wasn't received with gasps of horror. They were breaking new ground, reaching new frontiers, and the developers' reception was positive, if not giddy at times," the developer said.

But, "Unfortunately, you can't pull the same trick every couple of years. So, with the version 2.0, the focus has to be on smooth transition and backward compatibility," the developer concluded.

This article was originally published on Microsoft-Watch.com.

Discuss .Net Developers: 'What, Me Worry'?   >>> Be the FIRST to comment on this article!

>>> More Using VS Articles          >>> More By DevSource