Difference between .NET Framework 4.6, .Net Native and .Net Core

I see the following in almost every future .NET framework discussion:

• .NET Framework 4.6 (Full .Net framework)
• .NET Native
• .NET Core

What is the difference between all of these?

How do I know when to use the appropriate one?

After going through various links and videos, I found an interesting picture as a whole:

From the above, we could easily deduce the following:

• .NET Framework 4.6 is a full framework for everything related to .NET, but lacks libraries & runtime optimized for multi-platform (Windows, Linux and Mac) and cloud deployments
• .NET Core on the other hand is a subset of .NET Framework 4.6 which is mainly optimized for multi-platform and cloud deployments
• .NET Native is mainly used to develop Universal Apps which will be quite optimized to run on any device and platform, natively (not for the web apps though)

An interesting point is ASP.NET:

• If we need backward compatibility to the fullest extent (say web forms or aspx support), we need to go with .NET Framework 4.6
• If we develop MVC, Web API or Razor web pages, then we can deploy those web apps either in .NET Framework 4.6 or .NET Core environment

TLDR: If it's Core, it's a subset of functionality so it can be ran cross-plat. Anything you can run on Core can be ran on the full 4.6 framework for Windows.

.NET Framework v4.6 -- The full framework that can only run on Windows. However, because this is the full framework, that means you get WCF, WPF, and all functionality. You can think of this as your normal .NET Windows development that you're probably doing today. It does include ASP.NET WebForms, MVC, Core, and SignalR. If you're using .NET 4.5 today, this is your next natural upgrade path.

.NET Core -- A subset framework that doesn't include everything in the full 4.6 Framework. However it is intended to run cross-platform on Windows, Mac, or Linux. You do lose some functionality however, such as WCF, WPF. But you'll still have ASP.NET Core (no WebForms), but not SignalR yet. SignalR support is intended to come in a later version. This uses the dotnet CLI (command-line interface) for compiling applications, or if you're on Windows then you can use Visual Studio.

.NET Native -- Native compilation of the .NET Core framework. Instead of doing normal JIT compiling at runtime of your .exe, this will do an AOT compilation that can potentially do some better optimizations of your code using the C++ backend compiler (or LLVM using LLILC). When you do this, you are targeting a specific platform, such as "Linux 64-bit". The benefits are quicker start-up times, potentially smaller memory requirements, hopefully better runtime performance, and emits only one single binary file (you won't need to install the .NET Framework on the target machine). The tradeoff however is portability to other platforms--you'll have separate binaries for Linux, MacOS, Windows, 32-bit, 64-bit, etc. This currently only works for Windows Store apps but more work is being done so it'll work on normal .NET apps, including ASP.NET apps. Currently not slated to be part of the .NET Core 1.0 release.

ASP.NET Core -- The new way of doing web development on .NET Core or Full Framework. It includes a customizable HTTP pipeline, Kestrel web server, and better performance profiles than the previous ASP.NET 4.x version. This is cross-platform compatible across both the full framework and the Core framework. It does not include WebForms, or SignalR support (yet). It is not backwards compatible with ASP.NET 4, although if you're using MVC/WebAPI now, then MVC/WebAPI going forward should be fairly close since there will only be one Controller class. If you're wanting to use WebForms, then you have no choice but to stick with the full 4.6 Framework.

Entity Framework Core -- The new framework for ORM development. Once called EF7, it is the cross-platform ORM framework that works for both the full 4.6 stack and also the new Core stack. It is not backwards compatible with EF6. It only supports a code-first model. There may be tooling in the future to help upgrade existing EF6 .edmx files to generate the classes for code-first EFCore implementation.