The introduction of the .NET Core stack (and .NET Standard) has certainly been accompanied with some growing pains. The most prominent
(wildly discussed) example would be the change in project file format from .csproj (XML based) to .xproj (JSON based). And then back to .csproj.
The associated tooling has been somewhat rough around the edges (to a certain extent that still holds true today).

As a part of Microsofts remarkably more modern software development approach, a lot of the work is now performed out in the open on GitHub (with real community involvement as well). Changes occur frequently, resulting in a lot of
outdated information available online, undoubtedly causing some confusion for newcomers and seasoned veterans alike. That being said, .NET Core
still embodies some of the most fundamental (and ambitious) changes in the history of .NET.

Note: the following framework and tool versions were used for this blog post:

.NET Core Framework: 1.1.2

.NET Core Framework Host: 1.1.0

.NET Core Tooling (SDK): 1.0.4

In order to retrieve the shared framework host version, simply type dotnet at the command line:

The following section indicates this project is a command line application, targetting the .NET Core Framework, version 1.1 (the absence of the OutputType tag
would result in a class library being built instead):

Although strictly optional, defining those in the project file allows for the following incredibely convenient trick: dotnet pack -c release -o [myoutputdir] will
automatically generate us a (well specified) nuget package:

The advantages and disadvantages of each approach are explained quite well in the relevant sections of the documentation linked above.
For the purpose of this blog post, we will only focus on the
“self-contained” deployment model, which results in very “portable” binaries (in the sense that no assumptions about the
presence of a .NET Core runtime must be made). A “Hello World” SCD will weigh in at around 50Mb.

Target Operating Systems for Self-Contained Deployments

In order to configure a Self-Contained Deployment, we will add one or more RID (Runtime IDentifier) tokens to our project file. The presence (or absence)
of these tokens is what makes dotnet publish produce either a “Self-Contained” or “Framework-Dependent” build.