In this post, I will give you an overview of selecting a .NET edition over other, based on the services and features that each one will provide you with.
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.
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 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.
Figure 2: Columns of .NET family, each having an audience and a base foundation.
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.
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, 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:
| Feature/Requirement | Comments |
| Is Mature
| .NET Framework is a 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 same code base is open source. Maybe 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, 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 — 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 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 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 wirkflow. 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 cases, the 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 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 how graphical development might also start favoring .NET Core.
|
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.
- Mono
- 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.
- Introducing .NET Standard
Microsoft Azure
Do not forget, Microsoft Azure is the major platform, all of these changes are being made for.
- .NET open sourced, so that Linux and macOS can be targeted. Open source community can contribute.
- PowerShell — Automation tool — been open sourced. So, even from Linux clients can connect with Azure securely as instead of SSH etc.
- 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:
- You may publish it for others.
- You may reuse that library.
- You may reuse that code on other platforms — such as writing the service startup logic.
- 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
- 13th December, 2016: Initial version
