There are 2 ways of deploying .Net Core Applications:

  • Framework-dependent deployment (FDD)
  • Self-contained deployment (SCD)

Framework-dependent deployment

Framework-dependent deployments are where you already have the .NET Core Runtime installed on your machine and are just deploying the binaries of the application.

The benfits of FDD are:

  1. You do not have to define the target operating systems that your app will run on. This is because .NET Core uses a common PE file format.
  2. Multiple applications can use the same .NET Core installation
  3. The packaged application is a lot smaller than if you had used the SCD method

The main downsides are:

  1. The .NET Core Runtime could change without you knowing causing your application to break
  2. If the .NET Core runtime (or greater) that you are targetting is not present on the host, then your app will not run

An example of a .csproj file for a FDD published dotnet console app is:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.1</TargetFramework>
  </PropertyGroup>
</Project>

This app was simply created with the command dotnet new console. If you then run dotnet build you are ready to publish the app.

If you then run dotnet publish -f netcoreapp2.1 -c Release your app is published to bin>Release>netcoreapp2.1>publish directory

Note: Prior to .NET Core 2.0 you had to run dotnet restore before you could run dotnet build but as of .NET Core 2.0 dotnet restore is run implicitly by all commands that need a dotnet restore

Self-contained deployment

Self-contained deployments are where you publish your app and include the version of the .NET Core Runtime with your published package.

The benfit of SCD is:

  1. You are soley responsibe for the version of .NET Core that your app is running on and an accidental change on the host machine cannot happen

The main downside is:

  1. The packaged application is a lot larger (roughly 70MB for an empty dotnet console app compared to 20KB for FDD) than if you had used the FDD method as it includes the .NET Core runtime

An example of a .csproj file for a SCD published dotnet console app is:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <RuntimeIdentifiers>win10-x64;osx.10.13-x64</RuntimeIdentifiers>
  </PropertyGroup>
</Project>

As you can see the only difference here to the csproj from the FDD is the inclusion of the <RuntimeIdentifiers> element. Here is a link to the documentation showing the most common RIDs: https://docs.microsoft.com/en-us/dotnet/core/rid-catalog

This app was also created with the command dotnet new console. If you then run dotnet build you are ready to publish the app.

To publish this app to the 2 specified target runtimes, run these 2 commands:

  • dotnet publish -c Release -r win10-x64
  • dotnet publish -c Release -r osx.10.11-x64

You can the find the published apps at bin>Release>netcoreapp2.1>RuntimeIdentifier

For a much more thorough dive into .NET Core Deployments, the docs can be found here: https://docs.microsoft.com/en-us/dotnet/core/deploying/