Understanding .NET

.NET Framework, .NET Core, Xamarin, and .NET Standard are related and overlapping platforms for developers used to build applications and services. In this section, we're going to introduce you to each of these .NET concepts.

Understanding the .NET Framework

.NET Framework is a development platform that includes a Common Language Runtime (CLR), which manages the execution of code, and a Base Class Library (BCL), which provides a rich library of classes to build applications from. Microsoft originally designed the .NET Framework to have the possibility of being cross-platform, but Microsoft put their implementation effort into making it work best with Windows.

Since .NET Framework 4.5.2 it has been an official component of the Windows operating system. .NET Framework is installed on over one billion computers so it must change as little as possible. Even bug fixes can cause problems, so it is updated infrequently.

All of the apps on a computer written for the .NET Framework share the same version of the CLR and libraries stored in the Global Assembly Cache (GAC), which can lead to issues if some of them need a specific version for compatibility.

Understanding the Mono and Xamarin projects

Third parties developed a .NET Framework implementation named the Mono project. Mono is cross-platform, but it fell well behind the official implementation of .NET Framework.

Mono has found a niche as the foundation of the Xamarin mobile platform as well as cross-platform game development platforms like Unity.

Microsoft purchased Xamarin in 2016 and now gives away what used to be an expensive Xamarin extension for free with Visual Studio 2019. Microsoft renamed the Xamarin Studio development tool, which could only create mobile apps, to Visual Studio for Mac and gave it the ability to create other types of apps. With Visual Studio 2019 for Mac, Microsoft has replaced parts of the Xamarin Studio editor with parts from Visual Studio for Windows to provide closer parity of experience and performance.

Understanding .NET Core

Today, we live in a truly cross-platform world where modern mobile and cloud development have made Windows, as an operating system, much less important. Because of that, Microsoft has been working on an effort to decouple .NET from its close ties with Windows. While rewriting .NET Framework to be truly cross-platform, they've taken the opportunity to refactor and remove major parts that are no longer considered core.

This new product was branded .NET Core and includes a cross-platform implementation of the CLR known as CoreCLR and a streamlined library of classes known as CoreFX.

Scott Hunter, Microsoft Partner Director Program Manager for .NET, has said that "Forty percent of our .NET Core customers are brand-new developers to the platform, which is what we want with .NET Core. We want to bring new people in."

.NET Core is fast moving and because it can be deployed side by side with an app, it can change frequently knowing those changes will not affect other .NET Core apps on the same machine. Improvements that Microsoft can make to .NET Core cannot be added to .NET Framework.

Understanding future versions of .NET

At the Microsoft Build developer conference in May 2019, the .NET team announced that after .NET Core 3.0 is released in September 2019, .NET Core will be renamed .NET and the major version number will skip the number four to avoid confusion with .NET Framework 4.x. So, the next version of .NET Core will be .NET 5.0 and it is scheduled for release in November 2020. After that, Microsoft plans on annual major version releases every November, rather like Apple does major version number releases of iOS every second week in September.

The following table shows when the key versions of .NET Core were released, when future releases are planned, and which version is used by the various editions of this book:

I cannot promise 5th and 6th editions of this book to match future releases of .NET, but that would be a safe bet.

Understanding .NET Core support

.NET Core versions are either Long-Term Support (LTS) or Current, as described in the following list:

• LTS releases are stable and require fewer updates over their lifetime. These are a good choice for applications that you do not intend to update frequently. LTS releases will be supported for 3 years after general availability. .NET Core 3.1 will be an LTS release.

.NET Core 1.0 and 1.1 reached end of life and went out of support on 27 June 2019, 3 years after the initial .NET Core 1.0 release.

• Current releases include features that may change based on feedback. These are a good choice for applications that you are actively developing because they provide access to the latest improvements. After a 3-month maintenance period, the previous minor version will no longer be supported. For example, after 1.2 releases systems running version 1.1 will have 3 months to update to 1.2 to remain eligible for support. .NET Core 3.0 is a Current release so if .NET Core 3.1 releases in November 2019 as planned, then you will need to upgrade to it by February 2020.

Both receive critical fixes throughout their lifetime for security and reliability. You must stay up to date with the latest patches to get support. For example, if a system is running 1.0 and 1.0.1 has been released, 1.0.1 will need to be installed.

What is different about .NET Core?

.NET Core is smaller than the current version of .NET Framework due to the fact that legacy technologies have been removed. For example, Windows Forms and Windows Presentation Foundation (WPF) can be used to build graphical user interface (GUI) applications, but they are tightly bound to the Windows ecosystem, so they have been removed from .NET Core on macOS and Linux.

One of the new features of .NET Core 3.0 is support for running old Windows Forms and WPF applications using the Windows Desktop Pack that is included with the Windows version of .NET Core 3.0 which is why it is bigger than the SDKs for macOS and Linux. You can make some small changes to your legacy Windows app if necessary, and then rebuild it for .NET Core to take advantage of new features and performance improvements. You'll learn about support for building these types of Windows apps in Chapter 20, Building Windows Desktop Apps.

The latest technology used to build Windows apps is the Universal Windows Platform (UWP), which is built on a custom version of .NET Core. UWP is not part of .NET Core because it is not cross-platform.

ASP.NET Web Forms and Windows Communication Foundation (WCF) are old web application and service technologies that fewer developers are choosing to use for new development projects today, so they have also been removed from .NET Core. Instead, developers prefer to use ASP.NET MVC and ASP.NET Web API. These two technologies have been refactored and combined into a new product that runs on .NET Core, named ASP.NET Core. You'll learn about the technologies in Chapter 15, Building Websites Using ASP.NET Core Razor Pages, Chapter 16, Building Websites Using the Model-View-Controller Pattern, and Chapter 18, Building and Consuming Web Services.

Entity Framework (EF) 6 is an object-relational mapping technology that is designed to work with data that is stored in relational databases such as Oracle and Microsoft SQL Server. It has gained baggage over the years, so the cross-platform API has been slimmed down, will be given support for non-relational databases like Microsoft Azure Cosmos DB, and named Entity Framework Core. You will learn about it in Chapter 11, Working with Databases Using Entity Framework Core.

If you have existing apps that use the old EF then version 6.3 is supported on .NET Core 3.0.

In addition to removing large pieces from .NET Framework in order to make .NET Core, Microsoft has componentized the .NET Core into NuGet packages, those being small chunks of functionality that can be deployed independently.

Microsoft's primary goal is not to make .NET Core smaller than .NET Framework. The goal is to componentize .NET Core to support modern technologies and to have fewer dependencies, so that deployment requires only those packages that your application needs.

Understanding .NET Standard

The situation with .NET in 2019 is that there are three forked .NET platforms controlled by Microsoft, as shown in the following list:

• .NET Core: for cross-platform and new apps.
• .NET Framework: for legacy apps.
• Xamarin: for mobile apps.

Each has strengths and weaknesses because they are all designed for different scenarios. This has led to the problem that a developer must learn three platforms, each with annoying quirks and limitations. Because of that, Microsoft defined .NET Standard: a specification for a set of APIs that all .NET platforms can implement to indicate what level of compatibility they have. For example, basic support is indicated by a platform being compliant with .NET Standard 1.4.

With .NET Standard 2.0 and later, Microsoft made all three platforms converge on a modern minimum standard, which makes it much easier for developers to share code between any flavor of .NET.

For .NET Core 2.0 and later, this added a number of the missing APIs that developers need to port old code written for .NET Framework to the cross-platform .NET Core. However, some APIs are implemented, but throw an exception to indicate to a developer that they should not actually be used! This is usually due to differences in the operating system on which you run .NET Core. You'll learn how to handle these exceptions in Chapter 2, Speaking C#.

It is important to understand that .NET Standard is just a standard. You are not able to install .NET Standard in the same way that you cannot install HTML5. To use HTML5, you must install a web browser that implements the HTML5 standard.

To use the .NET Standard, you must install a .NET platform that implements the .NET Standard specification. .NET Standard 2.0 is implemented by the latest versions of .NET Framework, .NET Core, and Xamarin.

The latest .NET Standard, 2.1, is only implemented by .NET Core 3.0, Mono, and Xamarin. Some features of C# 8.0 require .NET Standard 2.1. .NET Standard 2.1 is not implemented by .NET Framework 4.8 so we should treat .NET Framework as legacy.

.NET platforms and tools used by the book editions

For the first edition of this book, which was written in March 2016, I focused on .NET Core functionality but used .NET Framework when important or useful features had not yet been implemented in .NET Core, because that was before the final release of .NET Core 1.0. Visual Studio 2015 was used for most examples, with Visual Studio Code shown only briefly.

The second edition was (almost) completely purged of all .NET Framework code examples so that readers were able to focus on .NET Core examples that truly run cross-platform. The third edition completed the switch. It was rewritten so that all of the code was pure .NET Core. But giving step-by-step instructions for multiple tools added unnecessary complexity.

In this fourth edition, we'll continue the trend by only showing coding examples using Visual Studio Code for all but the last two chapters of this book. In Chapter 20, Building Windows Desktop Apps, you'll need to use Visual Studio 2019 running on Windows 10, and in Chapter 21, Building Cross-Platform Mobile Apps Using Xamarin.Forms, you'll need to use Visual Studio 2019 for Mac.

Understanding intermediate language

The C# compiler (named Roslyn) used by the dotnet CLI tool converts your C# source code into intermediate language (IL) code and stores the IL in an assembly (a DLL or EXE file). IL code statements are like assembly language instructions, which are executed by .NET Core's virtual machine, known as CoreCLR.

At runtime, CoreCLR loads the IL code from the assembly, the just-in-time (JIT) compiler compiles it into native CPU instructions, and then it is executed by the CPU on your machine. The benefit of this three-step compilation process is that Microsoft is able to create CLRs for Linux and macOS, as well as for Windows. The same IL code runs everywhere because of the second compilation process, which generates code for the native operating system and CPU instruction set.

Regardless of which language the source code is written in, for example, C#, Visual Basic or F#, all .NET applications use IL code for their instructions stored in an assembly. Microsoft and others provide disassembler tools that can open an assembly and reveal this IL code like the ILSpy .NET Decompiler extension.

Understanding .NET Native

Another .NET initiative is called .NET Native. This compiles C# code to native CPU instructions ahead of time (AoT), rather than using the CLR to compile IL code JIT to native code later. .NET Native improves execution speed and reduces the memory footprint for applications because the native code is generated at build time and then deployed instead of the IL code.

Comparing .NET technologies

We can summarize and compare .NET technologies in 2019, as shown in the following table:

By the end of 2020, Microsoft promises that there will be a single .NET platform instead of three. .NET 5.0 is planned to have a single BCL and two runtimes: one optimized for server or desktop scenarios like websites and Windows desktop apps based on the .NET Core runtime, and one optimized for mobile apps based on the Xamarin runtime.