.NET officially becomes a Windows component
Microsoft is making some aggressive moves by slashing support of .NET 3.0 and 3.5 (without SP1) a year from now, on April 12th 2011. But the real deal is that .NET is no longer a “major product”, but rather a component of Windows.
Earlier versions of .NET were shipped as major products by the support lifecycle standards, and generally received 10 years of support from their release. Now, its support lifecycle will be attached to the Windows versions the framework ships on. Since .NET 3.5 SP1 ships with Windows 7 and Windows Server 2008 R2, it will be supported as long as those operating systems will be.
It also brings forth some new aspects for application supportability: You can easily end up in a situation where your .NET 3.5 SP1 is no longer supported on your Windows XP box, but it is supported on your Windows 7 machines. However, this connection between the framework and the OS does not mean that you couldn’t upgrade the .NET Framework separately from the OS – you certainly can. The newer versions will still have their lifecycle policies linked to the support policy of the OS.
Original announcement: http://support.microsoft.com/gp/lifeandotnet
Future .NET releases in tandem with the OS?
The role of a component is an interesting one, and has the potential to change how things evolve in the future. Take a look at PowerShell, for example: Starting in version 2, it shipped as an OS component. What this also means is that PowerShell v2 is unlikely to receive updates before SP1 for Windows 7 / 2008 R2 ships, and major changes will have to wait until the next edition of PowerShell, shipped alongside the next generation of Windows.
It implies a slower release rate, but of course, also more stable and predictable development. However, if we assume that future versions of .NET will ship together with Windows versions – a reasonable assumption I think – it does mean a couple of things.
First, major releases of Visual Studio are still likely to follow the release rate of .NET, binding even more products together. Second, Windows release dates are hard to push. If there is a .NET-specific problem late in the ship cycle, it was quite enough to move the .NET release date. It is far less likely to push a Windows release date, resulting in feature cuts.
But perhaps all of this was to be expected; after all, as Scott Hanselman has put it, “in .NET 4.0 the lego blocks are finally of the right size”. It is a mature framework, and rapid changes are no longer as necessary. However, it remains to be seen if this will turn out to be a hindrance to those products on a faster track: the cloud and Silverlight come to mind first.
May 3, 2010
В· Jouni Heikniemi В· No Comments
Tags: strategy, support В· Posted in: .NET, Windows IT
Leave a Reply