In the last several years, Microsoft has positioned itself as a strong supporter of Open Source Software and the Open Source Community in general. Some of the initiatives have included the embracing of Linux and Java in its development platform, Azure. But the biggest indicator that Microsoft has fully embraced the “open source way” is in its formation of the .NET Foundation, which is formed for the sole purpose of evangelizing the marriage of .NET and Open Source! As part of that initiative, the .NET Core platform was unveiled as a means to make the .NET languages cross-platform, modular as well as open source! The initial marketing message on .NET Core was a bit confusing. It was originally referred to as ASP.NET 5, which implied a continuation of the familiar .NET Framework. Later, however, it was rebranded to .NET Core, and it took off from there. But what exactly is the difference between .NET and .NET Core? Why would you choose one over the other? This post will try to demystify some of those questions and give you the edge you need to write code for the future!
You’ve got a massive backlog of classic .NET applications. Since .NET Core is clearly the way of the future, and the performance improvements have been proven and widely discussed, you want to start using it for new projects, and you’re thinking about migrating some of your old applications as well. In addition, over the years, your team has developed several well written .NET Framework libraries, and you’d like to make use of those in .NET Core. How do you even get started?
The first part of your plan when moving from .NET to .NET Core is to make sure you either have expertise in-house that understands the differences and interopability between .NET and .NET Core, or you hire a reputable partner like Software Design Partners to help you through it! Second, all of your developers should have a fairly good idea of the difference between .NET Framework, .NET Core and .NET Standard. To provide a very brief summary, .NET Standard is a specification, while .NET Framework and .NET Core are application frameworks. It’s very important to understand that both .NET Core and .NET Framework can both implement the .NET Standard, making libraries consumable across the 2 Frameworks. In other words, as long as a library implements the .NET Standard, you may reference the library from either .NET Core or .NET Framework, just as long as the framework version you are targeting implements the same .NET standard as your library.
You have approval for a new project to start up in your organization, and you’ve made the decision to use .NET Core for this new application. Some of the age old questions arise concerning issues that have cropped up whenever new major releases of .NET come out. Can the 2 major versions live side-by-side on the same machine? Are the 2 frameworks going to conflict with each other? Am I going to need to configure IIS differently when deploying web applications now? Thankfully, the answer to the first question is a resounding YES, .NET Core and .NET Framework can live together on the same machine without issue. The deployment scenario is fairly similar to deploying an old .NET 2.x application side by side with a .NET 4.x application, the global installations of the frameworks live in separate directories and don’t step on each other. In addition, .NET Core allows “self-contained” deployments, which will ship the entire lightweight framework alongside your application! This can be a great option when targeting specific or pre-release versions of the .NET Core framework and not wanting to deploy it machine-wide to your existing web servers.
Configuring IIS for .NET Core applications is again, fairly synonymous with the difference of deploying a .NET 2 application vs. a .NET 4 application. This time, though, IIS is actually configured to not use a .NET Framework at all, as the .NET Core pipeline is separated from the IIS worker process. This is a good thing as it opens up the ability to run ASP.NET Core apps inside of different web servers like Apache, Nginx or even a self-hosted web server!
As you develop more and more applications under .NET Core, you will inevitably want to consume those well-written, .NET Framework libraries that have been well tested and exercised in your organization for many years now. Can you just add a normal assembly reference to the old .NET library from a .NET Core application and expect it to work? Unfortunately, the short answer is no. However, because of .NET Standard, upgrading to a cross-framework compatible library should be a fairly straight-forward exercise. Libraries that are already built against .NET 4.5 or higher can simply be recompiled with the specification that they implement the appropriate .NET Standard version. This page provides a nice chart on the compatibility between .NET Framework, .NET Core regarding the .NET Standard specs they implement.
.NET Core is moving fast and furious! Due to the strong need for backward compatibility in the .NET Framework, Microsoft has admitted that they are innovating primarily on .NET Core now, while the classic framework will fall behind and have to catch up. If you don’t have a lot of Windows Forms or WPF applications in your environment, there is never going to be a better time than now to migrate your applications to .NET Core. While there are going to be some differences requiring rework of code due to missing APIs, the .NET Framework and .NET Core enjoy strong interopability right now. If you do have Windows Forms or WPF applications in your organization, .NET Core 3 will be adding Windows-Only support for those technologies, so your time to migrate is right around the corner! Regardless of when you migrate, you can expect a performance boost from migrating to .NET Core, as Microsoft has had performance in mind since the inception of .NET Core.
Let Software Design Partners help you create your strategy to move your applications into the future today! Implementing .NET Core is just the beginning of getting ready for the cloud-first, multi-device world that is already upon us!