Microsoft should be more conservative about changing fundamental technologies in .NET, especially when its changes require substantial developer rework and reverse previously stated directions.

The company’s recent decision to shift from LINQ to SQL on the ADO.NET Entity Framework was unsettling to some developers, and it contributed to the confusion regarding .NET libraries and consistency. Uncertainty is anathema to developers who might be considering .NET and who don’t want to be programming for a moving target.

Developers do not welcome breaking changes and do not want to be stuck using technologies that are initially encouraged by Microsoft, but then suddenly are rendered obsolete. The fact that Microsoft has committed to a 10-year support cycle for LINQ to SQL does not inspire confidence in the enterprise, where it is not uncommon for many applications to be decades old.

Since the .NET Framework’s introduction less than a decade ago, Microsoft has rapidly evolved it into a popular and productive platform for developers. The company deserves credit for its stewardship of the platform, but it needs to put the brakes on introducing new features that fragment the platform’s existing technologies.

We hear accounts from developers and partners alike that struggle to keep up with the pace of change to those technologies. Continuing down that path is the wrong thing to do for customers and for .NET.

While it is true that the core of .NET has changed very little from .NET 2.0, few developers work with the base class libraries alone. The foundations that were added with .NET 3.0, along with features such as LINQ, are at the heart of many enterprise applications.

By its own admission, Microsoft would have saved itself a year of effort had it realized that developers wanted synergies between its various technologies. It took a year to right that wrong in .NET 3.5.

Businesses are betting that .NET will be a viable long-term platform, and Microsoft’s partners have built businesses around it. While .NET is good, Microsoft’s inconsistency about APIs and supported technologies is not.