Risersoft
.NET is a framework that has been around in production since 2002. It’s the runtime behind numerous applications across a wide variety of platforms, such as Windows, Mac, and Linux. In recent history, .NET has moved to an open-source model as well, which allows anyone to contribute and collaborate with the .NET team members from Microsoft. However, with such a long history, it’s inevitable that some forms of divergence have occurred over time. Specifically, there are three main versions of .NET:
.NET Framework –This is the Windows-only version of .NET that has been the mainstay since day 1.
Mono – This is an open-source version of .NET that was maintained for many years outside of Microsoft, and was eventually acquired by Microsoft through their purchase of Xamarin.
.NET Core – This is Microsoft’s open-source, cross-platform version of .NET that was first released in 2016 and is currently on version 6.
As one could imagine, trying to maintain all three versions over time has its disadvantages. Furthermore, it’s clear that having a lean, cross-platform runtime is the choice for the future. Therefore, Microsoft announced that .NET would become one platform, designated as .NET 5 and beyond. One key point that is evident about .NET 5 and later versions is that the .NET Framework is “done” as of version 4.8. Microsoft will provide security and bug fixes as long as Windows is supported (.NET Framework is shipped with Windows as a core component) but no new features will be added, and the .NET Framework will always be Windows-only.
Building applications targeting the .NET Framework means you probably used frameworks to build either web sites or native Windows applications. Successfully porting these code bases to .NET depends on the frameworks in play. Here’s a synopsis of the major application types and modernization services on offer from Risersoft.
ASP.NET has a long history in .NET, and there are numerous ways to build web applications with this framework, such as Web Forms, MVC, and WebApi. With .NET Core, .NET developers can build REST APIs, web sites with MVC or Razor Pages, and client native applications using Blazor. In some cases, porting web APIs to .NET Core will mostly require changes to different types and methods now being used.
If applications were built with Web Forms, there’s no direct migration path available. Therefore, Web Forms applications may require a substantial amount of time to move to .NET Core. The only path forward is to rewrite the application into a modern, supported UI technology such as Razor Pages or Blazor.
WCF was heavily used for .NET Framework applications to build and host services. In .NET Core, there is no built in support for WCF. The best course might be to move to CoreWCF, which is a .NET foundation supported open source project. CoreWCF functions on top of Asp .Net CORE as a middleware, and aims to provide a smooth migration path to classic WCF applciations.
With .NET Core 3.0, support was added that allows Windows Forms and WPF applications to target the modern .NET runtime. This doesn’t mean that these applications are now cross-platform as these frameworks are Windows-specific. One good alternative is to stick with the desktop technology and make it compatible to run with cloud services to have the best of both worlds.
NuGet is the standard package system in .NET, with hundreds of thousands of packages available for developers to use in a wide variety of scenarios encountered in software development. At this point, many packages and components have been updated to support .NET Core and/or .NET Standard (a bridging technology to help migration from .NET Framework to modern .NET). It’s important to review all the packages and components used in an application and determine if any of them do not have support for at least .NET Core 3.1 and/or .NET Standard 2.0. If they don’t, decisions will have to made to either find another package with similar functionality or update the repository via a fork to support .NET Core.
With the .NET Framework, Windows is the only available platform to use. With .NET Core, code can be deployed to a wide variety of operating systems. This has the potential of lowering cost and improving performance. However, simply upgrading an application to .NET Core does not mean it can be hosted in Kubernetes or cloud-native environments running Linux. Depending on the specifics of the application structure, it may be detrimental to deploy to these newer targets. If your application has been designed using well-known principles of cloud-native, distributed, service architecture, you are in a better position to not only move off Windows, but to target different environments and operating systems.
As one could imagine, trying to maintain all three versions over time has its disadvantages. Furthermore, it’s clear that having a lean, cross-platform runtime is the choice for the future. Therefore, Microsoft announced that .NET would become one platform, designated as .NET 5 and beyond. One key point that is evident about .NET 5 and later versions is that the .NET Framework is “done” as of version 4.8. Microsoft will provide security and bug fixes as long as Windows is supported (.NET Framework is shipped with Windows as a core component) but no new features will be added, and the .NET Framework will always be Windows-only.
There’s one other area to consider. There are three language choices from Microsoft that target .NET: C#, F#, and VB. It’s interesting to note that in Microsoft’s 2017 language strategy blog post, it was stated that:
“We will keep Visual Basic straightforward and approachable. We will do everything necessary to keep it a first class citizen of the .NET ecosystem: When API shapes evolve as a result of new C# features, for instance, consuming those APIs should feel natural in VB. We will keep a focus on the cross-language tooling experience, recognizing that many VB developers also use C#. We will focus innovation on the core scenarios and domains where VB is popular.”
Fast-forward to 2020, and the story has arguably changed:
“We do not plan to evolve Visual Basic as a language. This supports language stability and maintains compatibility between the .NET Core and .NET Framework versions of Visual Basic. Future features of .NET Core that require language changes may not be supported in Visual Basic. Due to differences in the platform, there will be some differences between Visual Basic on .NET Framework and .NET Core.”
There are several ways to read between the lines, it is probably wise to start thinking about how to eventually move your applications from VB to C# or F#, especially in the event of application modernization projects.
Please check your uploaded file extension.
Please Select a file.