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.

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.

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:

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: