How To Select .NET Edition For Your Projects

Introduction and Background

Microsoft has released so many editions of .NET framework at the moment that it has already started to get a bit confusing,  and there is debate as to how to select which one over which. I haven't yet received any questions regarding .NET Standard but I have received quite a lot of questions, help queries etc. for .NET Core and I really believe that more of the beginners are diving into .NET Core as compared to .NET Framework -- one of the factors is me. I want them to go towards .NET Core. Every time someone comes to me and asks what should they be looking forward to, I say, go towards .NET Core and learn it. But .NET itself is also alive and Microsoft is delivering that too, but so is .NET Standard. So which one to choose?

Now, this is the question that I want to address in this post and I want to share my own opinions, along with some facts that you should consider while selecting a framework for your projects. I won't be speaking from a company consultant's point of view, nor would I be telling you which to use. I am a scholar, so I will focus on the needs of students as well as professionals -- since I happen to be that too.

Note - This won't be a long article, but just a reference piece of content that you can use to quickly make a decision as to use which one over the other.

Introduction To The Continuum

Well, there are many reasons why I must be writing this for you, and there are many reasons why I must stop from writing because all three of these frameworks (.NET framework, .NET Core, .NET Standard) are in a fight to be the successor in the Microsoft technologies. The answer itself is not very obvious as to whether we must invest any of our time in either of these frameworks or not. That has caused great confusion for me too, basically I never worked in the field of PCL systems in .NET framework when it began. However, I loved using .NET Core as it started and I have been working on .NET Core and many areas of it ever since the beta days. So, using a bit of history I want to clarify how these pieces all fit together.

It all started with the .NET framework we all are aware of. It was the framework that started "managed programming", using C# language, which just got introduced by that time, starting in the 2000s. Other languages like C++, Java etc. were all available however the proprietorship of Java by Oracle and memory management obstacles in C++ were a few of (only a few of) the reasons why Microsoft chose to develop a new language. C# was introduced since the start of .NET framework, it had features of both Java as well as C++ and was primarily object-oriented programming language. It was shipped as a proprietary Windows-only framework with a lot of huge advantages, community support, documentation and a lot of how-to samples for everyone to start up on. However, skipping decades of programming and focusing on "now", the priorities of Microsoft are shifting a bit in favor of open source and cloud computing. Their Azure product is something they are interested in more, Satya is interested in this -- as far as I can perceive.

If you somehow go to the Wikipedia page for Usage share of operating systems, you will find that Windows and Linux are always fighting. Mac OS is indeed present in a very strong place but it does not contribute to the fight at hand.


Figure 1 Graph representing overall percentage market shares of operating systems since 2002, to 2015; source Wikipedia.

Microsoft saw this as a big challenge for Azure — Why would they even build a cloud platform, if still the majority are going to run Linux? To tackle this, they started the "Microsoft ❤ Linux" program and started contributing toward the open source community. They started open sourcing products too, .NET framework was the start. Note that .NET was the start when Microsoft had the tools and had to build "great stuff" on top of it? Microsoft has to develop those tools on cross-platforms in order to start shipping their great stuff to other platforms. So, .NET was amended in various ways. What we are going to see here are a lot of things but primarily focusing on how it changed, and how you should change or adapt to these changes in your projects.

.NET Core and .NET Standard

Once the idea of this change is clear, we may want to understand what these two frameworks have for us. Simply speaking, .NET Core was created initially to support cross-platform development — it is worth mentioning that by cross-platform, I mean cross-operating systems too, as C# was used for cross-device programming for a while before (also see Notables section for mention of Mono framework). The platform started supporting Windows, Linux and Mac OS out of the box and you could write your applications that run on multiple platforms. It became a pillar in the .NET environment. MSDN kind of puts it all in a great format,


Figure 2 Columns of .NET family, each having an audience and a base foundation.

This shows how Microsoft had put forth the representation of how they are all going to fit together. They have their own base classes or core libraries, then they build up on top of them and you can select which you want to target, either Windows only, cross-platform, or mobile cross-platform (See Notables).

But if you try to understand this, you find a few things that cause it to be different. For instance, when you start building .NET Core applications, at a very high level they are similar, but small details have been modified to better suit needs. In such, one program cannot be compiled for other targets (say, Xamarin). The problem is a different foundation is being laid. Different structures, and ambiguity in the guarantee of a type, to the library are a few of these cases and thus the concept of "Continuum" cannot be put forth easily. So, they made a better environment,


Figure 3 One standard: .NET Standard to rules them all.

What happens now is that you get to work around on one library. So, in simple words, .NET Standard is just the "standard" that .NET Framework, .NET Core, Xamarin and other future derivatives have to follow so that you get the same behavior in the APIs provided. Although the problem of PCL still comes into play, like, what to do in cases where a library makes no sense for this target, such as the Registry of Windows on Linux and Mac OS etc.? But overall maximum room has been tidied up for the best.

So, up to this point, I hope the basic idea is clear. If so, I can continue and provide my own suggestions for everyone to select an edition,

Selection part

Now that we know what these frameworks are usually built for, and why they should be considered, for your applications. Without further ado,

Feature/Requirement	Comments
Is Mature	.NET framework is fully mature framework. .NET Core is also now released, it still requires improvements here and there, .NET Standard is still a baby!
Cross-platform support	.NET framework is a Windows-only framework, whereas .NET Core and .NET Standard are both cross-platform, and cross-operating systems or type too. I personally think, .NET framework will start shipping as an Add-on to Windows, and people will start installing .NET Core. Who knows? :-)
Open Source	.NET framework is not open source. .NET Core as well as .NET Standard are both open sourced projects under .NET Foundation. It is a bit of irony, .NET framework is not open source, whereas .NET Core having the same code base is open source. Maybe it's just a matter of saying it is.
Tools provided	All of them can be programmed using Visual Studio Community, Visual Studio Code. Xamarin projects under .NET Standard can be programmed in MonoDevelop too. All of the mentioned tools are free of cost. My recommendation is to use Visual Studio Community edition, but consider Visual Studio Code on Linux .
Documentation	Microsoft has provided support for .NET framework in a much better way, docs can be found on MSDN library. For, .NET Core and onwards they have created docs.microsoft.com website where future publications will be made. The mentioned website as of now is full featured, with an online compiler for .NET Core applications that you can use to learn the framework.
Language Support	.NET framework supports C++, C#, VB.NET, F# and much more based on what you use. .NET Core on the other hand supports C# and F# only. Same is the case for .NET Standard but it supports VB.NET too.
Desktop Apps	.NET itself targets only Windows desktops, but provides a lot of features and types of applications. .NET Core targets cross-platform machines, thus does not provides graphics library; but does support desktop development in console or terminal. .NET Standard is much like a library-developer platform. See below. .NET Standard provides underlying APIs to them. .NET Core can be used to build UWP applications too, which means you can use .NET Core and have a graphical application that runs on Windows 10 based machines — it does not mean you can use it on Linux, it's Windows only.
Web Apps	.NET and .NET Core have ASP.NET and ASP.NET Core application development frameworks respectively. They are very popular frameworks, so they both support the development. However, ASP.NET applications can only be hosted on a Windows-based web server — a Windows Server running IIS. ASP.NET Core can run on multiple platforms, using Kestrel, Apache, Nginx, etc. .NET Standard on the other hand should be considered for library development.
Graphical Apps	As mentioned in "Desktop Apps", .NET framework has the largest variety of GUI based application development frameworks — WPF, WinForms etc. .NET Core does not have any, because of the compatibility issues with Windows, Linux and macOS graphics libraries. In the future we may have one. Mobile Apps Only .NET Standard supports Xamarin for mobile development. Others are not intended to be used for such; .NET Core may evolve as one but I still wouldn't recommend using it on mobile platforms. Xamarin supports not just mobile, but UWP application development too.
Support for current frameworks	All of the current platforms support most of the platforms, libraries and tools. For instance, .NET and .NET Core have Entity Framework and Entity Framework Core respectively and can use them to execute SQL queries. The support will indeed continue. But the library might be written differently (e.g. Async functions).
Libraries	.NET, .NET Core and .NET Standard all can be used to build libraries. But to understand this you need to consider the purpose of libraries: Reusability. If you target, say .NET framework, your library will be available to Windows only. On the other hand, if you target .NET Standard, it will be available to Windows, while supporting Linux and macOS and mobile platforms too. This is why I recommend using .NET standard for your libraries.
Portability	In this case, targeting your application to .NET standard is indeed the best case as you get to target the maximum number of machines at the cost of a bit of APIs specific to a platform.
DevOps	All of these are Microsoft products and they are really good at DevOps tools and services, plus they give a good combination of services. For example you can use VSTS or Git for source control in all three of these frameworks.
Testing	Testing is also provided out of the box. There are third-party services too, that can help you decrease the error ratio
Database Connectivity	All of them provide base and concrete objects to work with databsases and manage the program workflow. System.Data.SqlClient for instance allows you to connect to SQL Server databases, you may also get other helpers for MySQL, MariaDB etc. So, in some cases, they frameworks are all same.
Visual Studio	Team Services integration: I have tried VSTS with .NET and .NET Core and all of the steps ranging from committing, to building, to deployment are similar. So, in these cases the framework doesn't matter at all.
My recommendation	If I have to make a choice: I'll go with .NET Core if I get an exception of graphics app. .NET Core is really interesting and an amazing platform. Plus it has a cleaner API set and you get to work with only the stuff that you need, removing all of the unwanted toppings from the applications. Since I do not do mobile applications, I do not find any reason to only target .NET Standard. If you want to build graphical application, then .NET might be good. See Notables as to how graphical development might also start favoring .NET Core.

This was just a handful of items or features that every team asks for before selecting a framework for development. I am sure I missed a few of them, so remind me and I would love adding them to the list. But remember all of these are subject to change over time and I might not be able to keep up with this table as the platforms update and improve their productivity.

You may simply read the comments from my experience and checklist which framework is better for your next project. I did not do a checklist-type table because that would have missed most of the explanation that a verbal table can easily provide to the audience. You have understood easily how the languages are supported in .NET Core and .NET framework, how would have I explained this in a checklist? Might as well have required images for samples and readmes for more on that. But you get the idea.

Notables — and final words

As promised above, I am providing a few of the reasons behind "why this articles is the way it is", so that the most of the critics might get an answer to this.

Mono Framework

I understand the fact that Mono was available for cross-platform development way before Microsoft had ever thought of it. I also happen to have a lot of articles covering those topics. But Microsoft has changed how it works, it's just .NET Core there now. You don't (and should not) use Mono because Mono is now underlying Xamarin only and the Xamarin team manages Mono — yes, you guessed it, Microsoft manages Xamarin now.

1. Mono
2. Xamarin

Problem still not solved

The problem that was originated is about platforms not being supported, API not available is still there. Although it's minimum, but it's present. You still have to use a lot of #if in your application to test what platform you are targeting and so on. I believe, simply, it would be much better rather than #if in these cases to let runtime decide what to do... Compile-time #ifs are not so good and efficient.

1. Introducing .NET Standard

Microsoft Azure

Do not forget, Microsoft Azure is the major platform all of these changes are being made for.

1. .NET is open sourced, so that Linux and macOS can be targeted. Open source community can contribute.
   
2. PowerShell — Automation tool — been open sourced. So, even from Linux clients can connect with Azure securely as instead of SSH etc.
   
3. Visual Studio Code made available, that has more than enough for developers on Linux.
   
   You can create any application and Azure has a solution for that — business done right!

Mobile development

Mono was an open source framework, its major usage was in Xamarin as a commercial product to build mobile applications from the same code base. How we learned these changes is above, and you saw how the basic implementation was designed to target one audience.

Now, all of that will be controlled by .NET Standard, as that will be the base of all of these frameworks.

Library development

This topic requires a bit more explanation. NuGet packages are the default source for packages and libraries in .NET Core and Standard. When you write a library, you write it so,

1. You may publish it for others.
2. You may reuse that library.
3. You may reuse that code on other platforms — such as writing the service startup logic.
4. You may port the code from one platform to others, even on mobiles or clouds.

But, .NET framework does not provide flexibility of cross-platform-ness. Every library package you write can be exposed to the external world, but after all is still a Windows-targeted library. Linux and macOS or mobile based versions would require a rewrite of that library. NuGet would be of use, but to Windows context only.

That is why, all of your library code must go to .NET Standard so that all of the platforms could be easily targeted and the changing the code, if required, is as painless as it can be.

Graphical applications

I mentioned that .NET framework has maximum support for graphical applications, indeed that is true. You can build any application, using any language, and then target a GUI framework (my favorite, WPF) so... That is simple. WinForms also provides a drag-n-drop way of doing this, a much simpler and more agile method in many cases where we can build GUI quickly. However, I also mentioned that .NET Core does not have any GUI based framework but .NET Standard might get one framework. If that happens, we might start supporting that on multiple platforms. There is work ongoing, maybe in the future but not at the moment.

Finally, ...

I recently stumbled upon this following document on GitHub by David Fowler, how .NET Standard relates to .NET Platforms and I believe it has answers to all of the problems that one might face while understanding the relations.

I hope, I have given a bit of an overview of what to expect from each of these frameworks and when to select or prefer which one.