Application Security Testing: An Integral Part of DevOps
Microsoft news: Here Microsoft goes at it again: fixing a wheel that ain't broke... Microsoft decided to shift from LINQ to SQL on the ADO.NET Entity Framework earlier this month. This decision was quite unsettling to some .NET developer, and it contributed to the confusion regarding .NET Framework libraries and consistency.
.NET 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.
.NET developers and partners alike struggle to keep up with the pace of change to these .NET technologies. Continuing down this current path that Microsoft is on, is the wrong thing to do for customers and for .NET.
The core of .NET Framework has changed very little from .NET Framework 2.0, few developers work with the base class libraries alone. The foundations that were added with .NET Framework 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 Framework 3.5.
Businesses are betting that .NET Framework will be a viable long-term platform, and Microsoft's partners have built businesses around it. While .NET Framework is good, Microsofts inconsistency about APIs and supported technologies is not and seems, never will be.
Microsoft news: Microsoft decided earlier this month to shift from LINQ to SQL on the ADO.NET Entity Framework