This is a series of blogs that will go through the vendor support lifecycles for the main technologies that we use and what options and approaches for upgrade paths there are available.
Recently, Microsoft have released into production the latest version of .net, their main application development technology. With this new release, version 5.0, they have consolidated the split between the .net framework and .net core (more on this later) and this event is a great time to review the current set of technologies that Software Solved use in our different services, and to talk about the best approach for keeping your software systems up to date and, more importantly, supported.
Let’s start with .net, while version 5 has brought the two mainstream versions of .net together with a clear view of what version to use for greenfield projects, the industry still has considerable investment in older versions so we can’t just write off nearly 20 years of existing technologies and only focus on the new shiny. Originally, there was the .net Framework. This is the framework that has been used to build and deploy .net based solutions since it was first released. Back in 2014 Microsoft announced the development of a new version of the .net framework, called .net Core. This was a re-write of .net, a faster more streamlined version, shedding some of the legacy functionality that was no longer relevant. .net Core was also implemented to be cross-platform so it was no longer tied directly to Windows. The first production release of .net core was released in 2016 and it has been the target of most enhancements and performance improvements for .net since.
Now, getting back to the point, what does this mean for long-term supportability for .net solutions? For the .net Framework, vendor support is linked to the version of Windows that that particular .net Framework version was included with. This then ties into Microsoft’s support model for their products. For Windows and the .net Framework, versions are covered by either ‘mainstream’ support or ‘extended’ support (or are out of support, of course). Mainstream support covers security functional issue resolution, while extended support still covers security fixes, but only critical functional issues that are major showstoppers. If you need support direct from Microsoft, it can become more expensive as the technologies you are using move into the extended support category.
Mainstream support usually lasts five years, with extended support lasting a further five years. The current latest version of the .net framework, 4.8, was released in 2019 and included in Windows 10 and Windows Server versions v1903 onwards. That means it will still be supported by Microsoft in 2029. If you’re relying on the .net Framework for your solutions, there’s no need to panic!
With .net Core, the support situation is different. Releases of .net Core are flagged as either LTS (Long Term Support) or ‘Current’. Major releases will alternate between LTS or Current release. LTS releases are supported for three years, or 12 months after the next LTS release, whichever is shorter. Current releases are only supported up to three months after the next release. Releases of .net Core are planned for every year.
While the latest release of .net is intended to be the one true framework moving forward, it isn’t actually an LTS release. The current LTS release is of .net Core is v3.1. This version was released in December 2019 and so will be fully supported by Microsoft until December 2022. Depending upon your project timetables and release plans, I would strongly consider .net Core 3.1 over .net 5.0 at this stage. I certainly wouldn’t want to deliver a large new system to users, only to immediately after the release have to make the decision between focusing on user feedback and staying on unsupported technology, versus spending effort upgrading to the next supported version of .net while users’ feedback is left behind.
Keeping .net Systems Current
The above information is all well and good, but how do we go about bringing a .net system in line with Microsoft’s support policy? How do we make sure our systems aren’t stuck in a technological dead-end?
The upgrade path from the .net Framework to .net Core is quite well defined but you have to be aware of which .net technologies that are available in the .net Framework are available in .net Core as not all of them are.
For Windows client/server applications, both WinForms and WPF are supported in .net Core, although the editing experience in Visual Studio isn’t quite as solid yet as it is for the .net Framework. For web applications and web API projects, ASP.NET MVC is supported but ASP.NET WebForms is not supported. WebAPI is supported but WCF is not supported. There is a community effort to implement WCF for .net Core (CoreWCF) but it is not yet production ready so Microsoft’s recommendations are to either migrate to REST-based services using WebAPI or to migrate to gRPC for binary remote procedure calls.
Whether your application uses a supported technology or not, the first step to migrating to .net Core is to upgrade your existing system to the latest .net version and then assess all the 3rd party libraries that your system uses to ensure they are fully supported on .net Core.
Once you’re aware of what work needs to be completed with the upgrades, you should review whether you’re going to need to migrated code from the older .net technologies to the latest versions, e.g. WebForms as discussed above.
Now, you can complete the process of moving the application source code to the newer project types for .net Core and validating the new build running on .net Core works as before.
For some systems, that can be a lot of work, and I’d like to reiterate that given the current state of Microsoft’s support models, there is no short-term urgency to this process, so it can be completed over an extended period of time, in line with other functionality improvements that you might have planned for a system. I do think it is important, however, to plan this work in, so that you’re not caught on a technology that doesn’t have any enhancements planned and limited to what options you have when it comes to improving your system.
In the next blog, we’ll look at other Microsoft technologies that we use and their support lifecycle and upgrade paths.
