It’s been a while since the .NET Core framework has been on the market (in fact a 2.0 version has just been released). However, a lot of companies are still resilient to migrate their projects into .NET Core (they ask the question “Does it worth to migrate?”, which is a perfectly valid question). Furthermore, many companies, even when starting a new project, opt to not take advantage of .NET Core and prefer to stick with the good old reliable classic .NET Framework.
The reason for not using .NET Core in project usually lies on decision makers that are afraid of unforeseen delays caused using new technologies. Many companies tend to wait until technologies reach a certain level of maturity before embracing them in their tool belt.
Hopefully, just like in the early versions of the .NET Framework, people will start to migrate as soon as they understand and feel more secure with .NET Core. Let’s try in this article to explain at high-level the changes that .NET Core brings, which may help you to convince people to adopt it sooner rather than later.
Multi-platform (this time it’s for real)
At the time .NET Framework came to life (for those that can remember), Java was in high demand on the market. And just like Java, the idea behind .NET was that anyone could make an implementation of a compiler that could compile files into the .NET intermediate language. In fact, if your memory is good you will even remember that they had an implementation of Java.NET (that did not evolve).
There you have it, you could choose any language (VB, Java, C++, or the newly created language C#) to use .NET. The only necessary thing was to install the .NET Framework into the machine (which later came with Windows Update making life even easier). An implementation of the .NET Framework for Linux was on the go (called Mono Project), however the interest of Microsoft to advance this project was questionable and Linux developers had often to deal with delays or faulty definitions.
With .NET Core, things seem to have started differently. Already available downloads for Mac and Linux were available on the website from the early beginning. This time, it seems that Microsoft is committed to provide the same .NET Core experience seamless of your device. To put in the words of Microsoft (https://docs.microsoft.com/en-us/dotnet/core/):
.NET Core can be thought of as a cross-platform version of the .NET Framework, at the layer of the .NET Framework Base Class Libraries (BCL). It implements the .NET Standard specification.
.NET Core & Core Libraries
We can think of .NET Core as a rewrite of the .NET Framework. This move was necessary if Microsoft wanted to create a multi-platform framework because the previous version of the .NET Framework was fragmented for the multiple platforms (Silverlight, Windows Phone, Windows Store). Initially, Microsoft thought in calling it .NET Framework 5 (last version being 4.6.x), but as this was a complete re-write of the .NET Framework with brand new concepts, they decided to re-start the numbering.
This implicated that other libraries would do the same… Entity Framework 6.1.x evolves to Entity Framework Core 1.0 (rather than version 7), ASP .NET 4.5 evolves to ASP.NET Core 1.0 (rather than ASP.NET 5). We must point out that for some libraries we can use the core version, without using the .NET Core framework. This is the case of ASP.NET Core 1.0 that can be used with .NET Framework 4.6:
It is important to note that .NET Core provides a subset of the APIs that are available in the .NET Framework. This means that, for some libraries, functionalities are either:
- Not implemented, but it will soon come in the following versions of the library;
- Not implemented, but it will never appear on the library;
- Implemented, sometimes with changes (e.g. functionalities moved somewhere else);
- Newly implemented and not available on the classic version of the library.
This leaves developers on a difficult position when deciding to migrate to the “Core” version of the libraries.
Certain features will be replaced by other technologies because they were problematic in some way (e.g. insecure, hard to maintain) and those will not be placed into Core. Among them:
WPF/XAML – The Windows Presentation Foundation is used to build user interfaces. The .NET Standard Library doesn’t include UI libraries and .NET Core doesn’t attempt to provide a cross-platform UI framework.
.NET remoting – In early versions of the .NET Framework (pre-dating Windows Communication Framework), remote objects were used to communicate between components. They have been succeeded by REST services.
Windows Communication Framework (WCF) services and ASMX – Web services development have been replaced by Web API. While it is still possible to use client features of WCF, .NET Core won’t contain classes for service creation.
In the few past years, Microsoft has embraced an open-source philosophy. Even if your company does not participate in open-source projects, this is a game-changer for developers. It is not rare that developers have a hard time using closed libraries, not understating what the code of the library was doing.
The first step was to expose the complete code of .NET Framework (available at http://referencesource.microsoft.com/). For .NET Core, a public GitHub was created and now anyone can propose change and make pull requests. This allows the community to be much more involved on the upcoming features of the framework (https://github.com/dotnet/core).
In conclusion, there are a few things worth to mention about .NET Core if you explain it to your boss:
- It’s multi-platform – if your intention is to deploy in multiple systems and devices, then look no further because .NET Core was made with that intention.
- .NET Core uses the same language and shares a few common libraries with .NET Framework but it should be considered a different stack from the classic framework. In fact, .NET Core and the classic framework can be on the same solution without much problem.
- .NET Core (and most of the libraries offered by Microsoft) is open-source and the contributions of the community will help to improve its evolution.
At first, .NET Core may seem like the logical choice for new projects (a bit less obvious to use in existing projects that started with the classic .NET Framework). Some questions should come to mind before deciding to choose .NET Core for a project (Are there any features that are not yet implemented? Is it interesting to run into another environment besides Windows?). Hopefully, the aspects presented in this article may help you decide when you are ready to embrace .NET Core in your projects.