.NET Core applications can be developed with Visual Studio on the Windows platform and Visual Studio for Mac (inheriting from Xamarin Studio) on macOS. Visual Studio Code (an open source project) and Rider (JetBrain's development IDE) provide support for both of these platforms, as well as Unix-based systems. While these platforms provide the desired user-friendly development UI, technically, .NET core applications can be written with a simple text editor and compiled using the .NET Core command-line toolset:
As we mentioned previously, the only intrinsic runtime in the .NET Core CLI is the .NET Core runtime, which is primarily used for creating console applications with access to the complete base class library.
Without further ado, let's create our first cross-platform application with the CLI tools and see how it behaves on multiple target platforms.
To begin with, we will create our console application on macOS that has .NET Core installed:
$ mkdir demo && cd $_ $ dotnet --version 2.1.301 $ dotnet new console The template "Console Application" was created successfully. Processing post-creation actions... Running 'dotnet restore' on /demo/demo.csproj... Restoring packages for /demo/demo.csproj... Generating MSBuild file /demo/obj/demo.csproj.nuget.g.props. Generating MSBuild file /demo/obj/demo.csproj.nuget.g.targets. Restore completed in 236.91 ms for /demo/demo.csproj. Restore succeeded.
Note
In this example, we have used the console template, but there are many other templates available out of the box, such as class library, unit test project, asp.net core, as well as more specific templates, such as razor page or MVC ViewStart.
Now, the helloworld console application should have been created in the folder that you specified in the first step.
In order to restore the NuGet packages associated with any project, you can use the dotnet restore
command in a command line or Terminal window, depending on your operating system.
Note
Generally, you don't need to use the restore command, as the compilation already does this for you. In the case of template creation, the last step actually restores the NuGet packages.
Now that our application project is ready (after editing the program.cs
file), we can build and run the console application:
Here, we used the run
command to compile and run our application in the current platform (macOS). If you were to navigate to the build
folder, you would notice that, instead of an executable, the CLI actually created a Dynamic Link Library (DLL) file. The reason for this is that, since no other compilation option was defined, the application was created as a framework-dependent application. We can try running the application with the dotnet
command, which is called the driver:
$ cd bin/Debug/netcoreapp2.1/ $ ls demo.deps.json demo.pdb demo.runtimeconfig.json demo.dll demo.runtimeconfig.dev.json $ dotnet demo.dll Hello .NET Core
Here, it is important to note that we used the description framework-dependent (in this case, the NETCore.App 2.1 runtime). If we were discussing the .NET framework prior to .NET Core, this would strictly refer to the Windows platform. In this context, however, it refers to an application that is only dependent on the framework itself while being platform-agnostic. In order to test our application on Windows, we can copy the bin folder to a Windows machine with the target framework installed and try running our application:
Note
In order to verify that the required framework is installed on the target machine, you can use the dotnet --info
or dotnet --list-sdks
commands, which will list the installed runtimes on the target machine.
In order to test the runtime independence of the created demo.dll
file, we can try running it with the mono runtime. On macOS, you can try the following command to execute our application:
$ cd bin/Debug/netcoreapp2.1/ $ mono demo.dll Hello .NET Core
In the previous example, we created a console application that is operating system-agnostic. However, it had a dependency on the NETCore.App
runtime. What if we want to deploy this application to a target system that doesn't have .NET Core runtime and/or SDK installed?
When the .NET Core applications need to be published, you can include the dependencies from the .NET Core framework and create a so-called self-contained package. However, by going down this path, you would need to define the target platform (operating system and CPU architecture) using a Runtime Identifier (RID) so that the .NET CLI can download the required dependencies and include them in your package.
The runtime can be defined either as part of the project file or as a parameter during publish
execution:
Here, we have edited the project file to target Windows 10 with the x64 architecture. Now, if we were to publish the application (note that the publishing process is going to take place on macOS), it would create an executable for the defined target platform:
$ nano demo.csproj $ dotnet publish Microsoft (R) Build Engine version 15.7.179.6572 for .NET Core Copyright (C) Microsoft Corporation. All rights reserved. Restoring packages for /demo/demo.csproj... Installing runtime.win-x64.Microsoft.NETCore.DotNetAppHost 2.1.1. Installing runtime.win-x64.Microsoft.NETCore.DotNetHostResolver 2.1.1. Installing runtime.win-x64.Microsoft.NETCore.DotNetHostPolicy 2.1.1. Installing runtime.win-x64.Microsoft.NETCore.App 2.1.1. Generating MSBuild file /demo/obj/demo.csproj.nuget.g.props. Generating MSBuild file /demo/obj/demo.csproj.nuget.g.targets. Restore completed in 18.81 sec for /demo/demo.csproj. demo -> /demo/bin/Debug/netcoreapp2.1/win10-x64/demo.dll demo -> /demo/bin/Debug/netcoreapp2.1/win10-x64/publish/
The publish
folder, in this case, would include all the necessary packages from the .NET Core runtime and framework targeting the Windows 10 runtime:
Notice that, once the deployment target platform is defined, an executable file is created and there is no more need for the driver. In fact, the executable's sole purpose here is to act as the access point (host) to the dynamic class library that is created by .NET Core.
Some of the most notable runtimes include Windows 7 to Windows 10 on three different architectures (x86, x64, and arm), multiple macOS versions, and various distributions and versions of Linux, including OpenSuse, Fedora, Debian, Ubuntu, RedHat, Tizen, and so on.
In the previous examples, we have been using netcoreapp2.1 as the target framework. While, for the self-contained deployment for this console application, this proves to be sufficient, if we were preparing a Xamarin application or a UWP. Net Standard, we would have been better off using target platform frameworks such as Xamarin.iOS.
The target platform framework can be changed using the <TargetFrameworks>
project property. We would have to use the moniker assigned to the desired framework:
Target framework | Latest stable version | Moniker | .NET Standard |
.NET Standard | 2.0 | netstandard2.0 | N/A |
.NET Core | 2.1 | netcoreapp2.1 | 2.0 |
.NET Framework | 4.7.2 | net472 | 2.0 |