News

.NET 4 Versions End of Life Here Before Devs Know It

.NET vNext isn't here just yet, but Microsoft wants developers to move on to .NET Framework 4.5.2 as soon as possible, with support for versions 4 up to 4.5.1 ending mid-January 2016.

While .NET vNext is getting spit-polished for general availability some time in 2015, there's still the business of making sure apps and services continue to move along and adopt the latest and greatest, which often means relegating legacy apps to the past. With that, the .NET Fundamentals Team offers fair warning more than a year in advance of ending support for .NET Framework 4.5.1 and older in a blog it posted last week. With that idea put forth, Microsoft announced late last week that it is changing its product lifecycle support policy, but just for those older .NET Framework 4 and 4.5 versions.

The most recent version of the .NET Framework, version 4.5.2, was released in early May. That version came mostly with a number of new features in ASP.NET (new and improved APIs, and improvements in the building of Windows Forms, improved Async, improved shared hosting), and was released as an in-place upgrade quickly after version 4.5.1 (which was released in October 2013). The team blogs that versions 4.x through 4.5.1 will not be supported after Jan. 12, 2016.

The warning 15 months before end of life might seem like a long lead time, but the team said that changes to .NET are being made much more quickly, and the regularity of updates often mean that "the latest fixes, features and innovations are available in the latest version and not in legacy versions." In essence, Microsoft will be reducing the product lifecycles of these older .NET Framework versions 4 and 4.5 and imposing the Jan. 12, 2016 end-of-"extended support" date on them. Typically, those older .NET Framework versions 4 and 4.5 would have the same extended support lifecycles as the server products running on them, but Microsoft will impose what amounts to be an earlier end-of-support date in those cases. The good news, Microsoft claims, is that the .NET Framework 4.5.2 is considered to be an "in-place update" to the .NET 4 family, with no need to recompile applications.

The team understands that transitions to newer versions won't be completely smooth, and writes that there are a small number of changes included in newer versions that may be deemed breaking changes due to some incompatibility with older versions. "We include these changes only when absolutely necessary in the interests of security, in order to comply with industry-wide standards, or in order to correct a previous incompatibility within .NET." The team includes a link to a list of application compatibility with various versions of .NET here.

As a side note, the team said an exception, the .NET Framework 3.5 SP1, which is a version of .NET that's deployed alongside the .NET Framework 4.x and is often used in various older products. Versions of Windows Server 2008 and SQL Server 2008 still rely on the .NET Framework 3.5. Versions of Windows Server 2008, according to a search on the Microsoft Product Lifecycle page, have extended support until 2020. Hence, in a peculiar twist, servers running the older .NET Framework 3.5 can have a longer .NET Framework product lifecycle than servers running the older .NET Framework versions 4 and 4.5.

All of this busywork is aimed at getting developers up to speed on .NET vNext, the working code name for the next version of the .NET Framework that's expected some time in 2015. That version was previewed at the recent Build and TechEd conferences this year, highlighting the Framework's evolution to a "mobile-first, cloud-first" platform. It's a slimmed-down version that runs .NET libraries based on the user environment, which deploys runtime and framework libraries as apps need them. The team said that a cloud-optimized mode doesn't include Windows Presentation Foundation (WPF) and Windows Forms libraries, for example.

Details are scant elsewhere in a search of various Microsoft blogs, but there's as good a detailed description of it at this .NET Team blog post from May.

Kurt Mackie, senior news producer for the 1105 Enterprise Computing Group, contributed to this report.

About the Author

You Tell 'Em, Readers: If you've read this far, know that Michael Domingo, Visual Studio Magazine Editor in Chief, is here to serve you, dear readers, and wants to get you the information you so richly deserve. What news, content, topics, issues do you want to see covered in Visual Studio Magazine? He's listening at [email protected].

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube