As the newest members of the .NET family, there’s much confusion about .NET Core and .NET Standard and how they differ from the .NET Framework. In this article, I’ll explain exactly what each of these are and look at when you should choose each one.
Before going into detail, it’s helpful to look at the larger picture of .NET to see where .NET Core and .NET Standard fit in. When.NET Framework first shipped 17 years ago, it had a single .NET stack that you could use for building Windows desktop and Web applications. Since then, other .NET implementations have emerged, such as Xamarin, which you can use for building mobile apps for iOS and Android, as well as macOS desktop applications
Here’s how .NET Core and .NET Standard fit into this:
- .NET Core: This is the latest .NET implementation. It’s open source and available for multiple OSes. With .NET Core, you can build cross-platform console apps and ASP.NET Core Web applications and cloud services.
- .NET Standard: This is the set of fundamental APIs (commonly referred to as base class library or BCL) that all .NET implementations must implement. By targeting .NET Standard, you can build libraries that you can share across all your .NET apps, no matter on which .NET implementation or OS they run.
Introduction to .NET Core
.NET Core is a new cross-platform and fully open source .NET implementation that was forked from .NET Framework and Silverlight. It’s optimized for mobile and server workloads by enabling self-contained XCOPY deployments.
To get a better feel for .NET Core, let’s take a closer look at what developing for .NET Core looks like. And let’s do this while exploring the new command line-based tooling. You can also use Visual Studio 2017 for your .NET Core development, but because you’re reading this article, chances are you’re quite familiar with Visual Studio already, so I’ll focus on the new experience.
When .NET was created, it was heavily optimized for rapid application development on Windows. In practice, this means that .NET development and Visual Studio were inseparable friends. And sure thing: Using Visual Studio for development is a blast. It’s super productive and the debugger is hands down the best I’ve ever used.
However, there are cases where using Visual Studio isn’t the most convenient option. Let’s say you want to just play with .NET to learn C#: You shouldn’t have to download and install a multi-gigabyte IDE. Or, say you’re accessing a Linux machine over SSH where using an IDE is simply not an option. Or, say you’re simply someone who prefers using a command-line interface (CLI).
That’s why a first-class CLI was created, called .NET Core CLI. The .NET Core CLI’s main driver is called “dotnet.” You can use it for virtually all aspects of your development, including creating, building, testing and packaging projects.
Introduction to .NET Standard
When you’re building modern experiences, your app often spans multiple form factors and, therefore, multiple .NET implementations. In this day and age, customers pretty much expect that they can use your Web app from their mobile phone and that data can be shared via a cloud-based back end. When using a laptop, they also want to get access via a Web site. And for your own infrastructure, you likely want to use command-line tools and potentially even desktop apps for letting your staff manage the system.
Figure 5 Descriptions of .NET Implementations
|.NET Framework||Windows||No||Used for building Windows desktop applications and ASP.NET Web apps running on IIS.|
|.NET Core||Windows, Linux, macOS||Yes||Used for building cross-platform console apps and ASP.NET Core Web apps and cloud services.|
|Xamarin||iOS, Android, macOS||Yes||Used for building mobile applications for iOS and Android, as well as desktop apps for macOS.|
|.NET Standard||N/A||Yes||Used for building libraries that can be referenced from all .NET implementations, such as .NET Framework, .NET Core and Xamarin.|
In such an environment, code sharing becomes a major challenge. You need to understand where APIs are available and make sure that shared components only use APIs that are available across all .NET implementations you’re using.
And that’s where .NET Standard comes in. .NET Standard is a specification. Each .NET Standard version defines the set of APIs that all .NET implementations must provide to conform to that version. You can think of it as yet-another .NET stack, except that you can’t build apps for it, only libraries. It’s the .NET implementation you should use for libraries that you want to reference from everywhere.
You’re probably wondering which APIs .NET Standard covers. If you’re familiar with .NET Framework, then you should be familiar with the BCL, which I mentioned earlier. The BCL is the set of fundamental APIs that are independent of UI frameworks and application models. It includes the primitive types, file I/O, networking, reflection, serialization, XML and more.
All .NET stacks implement some version of .NET Standard. The rule of thumb is that when a new version of a .NET implementation is produced, it will usually implement the latest available version of the .NET Standard.
A good analogy is HTML and browsers: Think of the HTML specification as the .NET Standard and the different browsers as the .NET implementations, such as .NET Framework, .NET Core and Xamarin.
.NET Standard is a specification of APIs that all .NET implementations must provide. It brings consistency to the .NET family and enables you to build libraries you can use from any .NET implementation. It replaces PCLs for building shared components.
.NET Core is an implementation of the .NET Standard that’s optimized for building console applications, Web apps and cloud services using ASP.NET Core. Its SDK comes with a powerful tooling that in addition to Visual Studio development supports a full command line-based development workflow. You can learn more about them at aka.ms/netstandardfaq and aka.ms/netcore.