Writing code that runs on multiple platforms not only is a dream for many developers, but it is becoming more and more a requirement in the market. In fact, many companies already have (and many others are considering having) platform-specific versions of applications that run on Windows, macOS, and Linux (and its popular distributions). When it comes to web applications and services, the technology you use to build the app or service has an impact on the host you will use. For example, web applications or services built with the .NET Framework can be hosted only on Windows servers (including Azure as the host) but not on Linux servers.
Because server distributions of Linux are extremely popular and you probably have customers that want apps and services to be hosted on Linux servers, you cannot satisfy your customers if your (or your team’s) expertise is only in C# and the Microsoft stack. In the last few years, Microsoft has been working hard to bring its most popular development technology and programming language, .NET and C#, to all the most important operating systems. The resulting work is .NET Core, a cross-platform development technology that runs on Windows, macOS, and Linux. Visual Studio for Mac supports .NET Core to build applications in C# and F#, and this chapter provides a high-level overview of the architecture of the platform, before you start writing some code in the next two chapters. It is worth mentioning that all the theoretical concepts discussed in this chapter apply to all .NET Core versions, but the command-line tools and options refer to versions 1.1 and 2.0.
Note
The purpose of this chapter is to introduce .NET Core, focusing on the concepts you need to build ASP.NET Core MVC applications and ASP.NET Core Web API services, described in Chapter 10 and 11, respectively. The full, official documentation for .NET Core is available at http://docs.microsoft.com/en-us/dotnet/core/ .
What Is .NET Core?
At a high level, you can think of .NET Core as a subset of the .NET Framework that runs on Windows, macOS, and Linux.
More specifically, .NET Core is a cross-platform, open source, modular, and general-purpose development platform included in the .NET Foundation ( http://dotnetfoundation.org ) that Microsoft supports and maintains, together with the .NET developer community, at http://github.com/dotnet/core . .NET Core also runs on devices, which may include mobile devices and IoT devices; therefore, it is not limited to classic desktop and server environments. It is a modular framework in that it ships as NuGet packages, and the idea is that an app built on top of .NET Core will include only the libraries (modules) it actually needs, instead of relying on a full framework like with the .NET Framework. To build applications with .NET Core, you need to download and install the .NET Core SDK, which includes all the tools described in the next subsections and everything you need to build, test, run, and publish your work. As you learned in Chapter 1, Visual Studio for Mac takes care of installing the .NET Core SDK on your behalf. Similarly, if you work on Windows, the Visual Studio Installer for Visual Studio 2017 takes care of installing the .NET Core SDK. If you instead want to use .NET Core on Linux, you must download and install the SDK manually from www.dot.net . Now I will provide you with some information about the architecture of .NET Core, introducing concepts that you must know when building applications and services on top of this framework.
Understanding the Architecture of .NET Core
.NET Core consists of several fundamental parts that work together to bring all the power, flexibility, and compatibility to this amazing technology. The following subsections provide a high-level overview of the parts that comprise .NET Core.
The .NET Core Runtime
The .NET Core runtime , known as the CoreCLR , is a portable, cross-platform component that provides applications with an execution environment. The CoreCLR includes a type system with base .NET data types, a just-in-time (JIT) compiler, a garbage collector, and a base class library called mscorlib. CLR stands for Common Language Runtime, and it basically means that all .NET apps run on the same runtime platform regardless of the programming language they have been written with.
Differently from the full .NET Framework, where applications need .NET to be installed on the target system to take advantage of the Common Language Runtime, with .NET Core the CoreCLR is packaged together with the application and the required libraries. This avoids the need for a pre-installed runtime. The CoreCLR is an open source project available at http://github.com/dotnet/coreclr .
.NET Core Libraries
While the .NET Core runtime includes the base class library, additional types are necessary for serious development. .NET Core provides a large number of libraries that ship as NuGet packages and that expose types for file access, collections, XML, and so on.
Providing the full list of .NET Core libraries is not necessary since Visual Studio for Mac will automatically include the appropriate libraries when creating MVC and Web API projects.
Note
If you are curious, you can open the Nuget.org web site and type .NET Core in the search box. The libraries that are considered part of the .NET Core architecture are recognizable by names that start with System.
.NET Core SDK: Tools and Languages
The .NET Core SDK is the set of tools you need to build applications for .NET Core. This includes the .NET command-line interface (CLI) and the programming languages with compilers. The command-line interface is covered in more detail in the next section, so I’ll say a few words about programming languages.
Currently, .NET Core 2.0 allows you to write applications using C#, F#, and Visual Basic. The implication is that you can write C#, F#, and Visual Basic code not only on Windows, as you could do in the past, but also on macOS and Linux. This is possible because Microsoft has been working hard to make these popular programming languages cross-platform. In addition, they have been open sourced and offered to the developer community under the name of .NET Compiler Platform, often referred to as Project Roslyn ( http://github.com/dotnet/roslyn ). With Roslyn, compilers are no longer black boxes that only generate binaries from source code; now they expose the APIs a developer can use to perform code analysis and code generation. Actually, Visual Studio for Mac and Visual Studio 2017 on Windows themselves use the Roslyn APIs to analyze the source code as you type and to report diagnostic information.
Getting Started with the Command-Line Tools
For the sake of platform independence, .NET Core does not need any IDE to create and manage applications, and it allows you to perform all the necessary operations from the command line, including creating, building, running, testing, and publishing applications, plus managing NuGet packages. What you need is just a code editor to write source code.
In .NET Core, the CLI provides the dotnet command-line application that offers a number of built-in options and that can be extended through special NuGet packages (an example of this will be provided in the next two chapters). Table 9-1 summarizes the most common command-line options available with dotnet.exe.
Table 9-1. Most Common Command-Line Options for dotnet.exe
Option | Description |
|---|---|
new | Generates a new .NET Core project based on the specified template |
restore | Restores the NuGet packages for a .NET Core project |
build | Builds a .NET Core project |
puslish | Packs an application and its dependencies into a folder on the local file system for later publishing to a host |
run | Starts a .NET Core application (if a build is not found, it first builds the project) |
clean | Cleans the output of a project |
pack | Generates a NuGet package from a .NET Core class library project |
test | Executes unit tests in a .NET Core project |
vstest | Runs UI tests in a file |
sln | Allows you to manage MSBuild solution files by adding and removing projects |
In most cases, command-line options need further specifications. For example, the new option, which allows you to create a new project, requires you to specify a project template, such as a console or web application, and optionally the programming language between C# and F#. Table 9-2 summarizes the available templates for the dotnet new command.
Table 9-2. Available Templates for .NET Core Projects
Name | Description | Language |
|---|---|---|
console | Console application | C#, F#, VB |
web | Empty web project | C#, F# |
mvc | Web project based on MVC with controllers and views | C#, F# |
webapi | Web API project for RESTful services | C#, F# |
classlib | .NET Standard class library | C#, F#, VB |
mstest | Unit test project | C#, F#, VB |
xunit | xUnit test project | C#, F#, VB |
nugetconfig | NuGet configuration file | |
webconfig | Configuration file | |
sln | Solution file |
Creating new projects with the .NET command line is easy. First you create a subfolder that will contain the new project, and then you open a Terminal instance on that folder; you then type the dotnet command followed by the project template, and .NET Core will generate a new project whose name is based on the name of the subfolder you created. For example, the following command line allows you to scaffold a new ASP.NET Core project based on the MVC architecture in the current folder:
> dotnet new mvcIf no language is specified, the default is C#. With supported templates , you can specify F# with the following command line:
> dotnet new mvc -lang f#When you call dotnet.exe to generate a new project, it creates a .csproj file for C# projects (or .fsproj for F#), based on the typical XML structure that Visual Studio projects have always had on Windows, together with all the files that are necessary to the project based on the selected template.
Once you have created a project, you can use your favorite IDE to work with it, such as Visual Studio Code ( http://code.visualstudio.com ). Obviously, in this book you will see how to use Visual Studio for Mac as the development environment for .NET Core projects. .NET Core projects typically need some NuGet packages, so once a project has been created, you need to first do a package restore with the following command directly in the project directory:
> dotnet restoreIf you want to include additional NuGet packages, with the code editor of your choice you need to edit the .csproj project file and add a line like the following within the ItemGroup node that contains PackageReference elements:
<PackageReference Include="PackageName" Version="1.0.0" />PackageName is the fully qualified NuGet package name. Remember to run dotnet restore every time you add NuGet packages. Whatever editor or IDE you choose to work with .NET Core, you can then simply build and run your project with the following:
> dotnet runThis command first builds the project if .NET Core finds no builds. You can also manually launch the build process with the following:
> dotnet buildAs you might understand, except for source code editing, anything you need to create, build, and run a .NET Core project can be done with the dotnet.exe tool. This is certainly a powerful application, but doing the whole job from the command line can be painful, especially with large, enterprise projects. Luckily, with Visual Studio for Mac you do not need to interact with .NET Core from the command line since the IDE offers menu commands that make it easy to create, build, debug, and run these kinds of .NET projects via a convenient user interface, invoking the proper dotnet commands on your behalf. In the next chapters, you will see how Visual Studio for Mac makes dramatically easy-to-create and manage ASP.NET Core MVC and Web API projects.
Understanding the Relationship Between .NET Core with .NET Standard
In the early chapters, I explained that .NET Standard ( http://docs.microsoft.com/en-us/dotnet/standard/library ) is essentially a formal specification of APIs. Implementations of .NET that implement the .NET Standard specification can be considered as .NET Standard compliant and can support .NET Standard libraries.
.NET Core implements .NET Standard, and it exposes a subset of the APIs that are included in the .NET Framework and Mono.
Summary
In this chapter, you got familiar with .NET Core through a high-level overview of the platform. First you were presented with explanations about its cross-platform architecture built upon a number of pillars such as the .NET Core Runtime (CoreCLR), the .NET Core Libraries, and the .NET Core SDK. The latter includes the dotnet.exe command-line tool and the C# and F# compilers, powered by the .NET Compiler Platform (also known as Roslyn).
Except for editing source code, which requires an editor, you can create, build, test, and run .NET Core applications using the dotnet.exe tool and passing the proper command-line switches. You can also quickly restore NuGet packages. After some examples of command lines, the chapter provided some interesting considerations about the relationship between .NET Core and the .NET Standard specifications, which you should keep in mind when thinking about libraries you can both consume and build in .NET Core. Now that you know what .NET Core is, it is time to build some cross-platform applications with Visual Studio for Mac, starting with an MVC application in the next chapter, and continuing with a Web API service in Chapter 11.