Selection of .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 of confusion and debate about which one to select over others? I haven't yet received any questions regarding the .NET Standard, but I have received quite a lot of questions, help queries, etc. for .NET Core and I really believe that more beginners are diving into .NET Core as compared to .NET Framework -- one of the factors is me, I want them to go toward .NET Core. Every time someone comes to me, and asks me what they should 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 basically choose?

So, this is the question that I want to address in this post of mine and I want to share my own opinions, and some facts that you should consider while selecting a framework for your projects. I won't be speaking from a company's consultant's point of view and nor would I be telling you which to use. I am a student and 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. I also compiled a video on YouTube, What is difference in .NET Framework and .NET Core and .NET Standard.

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 much obvious as to whether we must invest any of our time in either of these frameworks or not. That has caused a great confusion to 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 of 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 an Object-oriented programming language. It was shipped as a proprietary Windows-only framework with many huge advantages, community support, documentation and a lot of how-to samples for everyone to start up on. However, skipping decade 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 somewhat they are interested in more, Satya is interested in this -- the way 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 in hand.

Microsoft saw this as a big challenge for Azure — Why would they even build a cloud platform, if still maximum 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. Noted 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-platform 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 since 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.

This shows how Microsoft had put forth the representation of what they are all going to fit together as. 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 as, 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 higher 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 different foundation being laid. Different structures, and ambiguity in 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.

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, upto 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 build for, and why they should be considered, for your applications. Without further ado:

This was just a handful of items or features that ever team ask for before selecting a framework for development. I am sure I missed a few of them out, 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 these tables 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 explanation that 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 checklist? Might have as well 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 reasonings behind "why this articles is the way it is", so that 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 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 about platforms not supported, API not available is still there. Although minimum, but 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, simple if 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 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 same code base. How we learnt these changes above and how you saw 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 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 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 code changing, if required, is as much less painful 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, much simple and agile method in many cases where 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 working ongoing, maybe in 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 might have given a bit of overview of what to expect from each of these frameworks and when to select or prefer which one.

History

• 13^th December, 2016: Initial version