Few days ago I blogged about .NET Standard, .NET Core and .NET framework and I think it might be a goo idea to write something about .NET Core today. .NET Core is an open source, cross platform development framework in the .NET world. What I would like to do today is to show how to deploy a .NET Core console application using command line. This is nothing complicated or particularly useful, but it will help to get a better understanding on what “cross platform” means. I will use Visual Studio Code and the integrated terminal to run the needed commands.

Create the application

The first step is, of course, to create the console application. In order to do this, we can create a new folder (anywhere you want). Then right click the folder and click on “Open with Visual Studio Code”. Then, display the integrated terminal pane. Of course, this will be available if you install the software first. You can follow these steps also with the code editor of your choice. The only important thing is to have a command line opened in the folder we will work in.

To create a new console application in the specified folder, just run the following command:

Now you’ll notice that two files are created: a .csproj file and Program.cs. As you know, Program.cs is where you start to write your code while .csproj is a ery important configuration file. To go further you can either use the already populated code in Program.cs (a simple “Hello World”) or you can write your own code to make it a little bit more interesting. If you’re lacking any ideas, here is a C# code sample that will write the first 15 elements of the Fibonacci sequence:

[code language=”csharp”]
using System;

namespace Core
{
class Program
{
static void Main(string[] args)
{
Fibonacci();
}

static void Fibonacci ()
{
int a = 0;
int b = 1;
int counter = 15;
for (int i = 0; i <= counter; i++)
{
int temp = a;
a = b;
b = temp + b;
Console.Write($”{b}, “);
}

}
}
}
[/code]

Run the application

Now we can already test the application. First let’s run the following command:

[code language=”bash”]

dotnet restore

[/code]

It is always a good idea to first run the “restore” command since calls into NuGet (.NET package manager) to restore the tree of dependencies. NuGet analyzes the Hello.csproj file, downloads the dependencies stated in the file (or grabs them from a cache on your machine), and writes the obj/project.assets.json file. The project.assets.json file is necessary to be able to compile and run. Afterwards, we can run the application:

[code language=”bash”]

dotnet run

[/code]

This will display the Fibonacci sequence in your integrated terminal.

Deploy the .NET Core console application

So now we’re ready for the deployment. It’s not particularly difficult, but here we’ll be able to see what .NET Core is all about. To deploy the application simply run:

[code language=”bash”]
dotnet publish -f netcoreapp2.0 -c Release
[/code]

Here we need to be careful! what comes after “-f” needs to match exactly the target framework in the .csproj file:

[code language=”csharp” highlight=”4″]

<Project Sdk=”Microsoft.NET.Sdk”>
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
</Project>

[/code]

If it’s not the same, you will get an error. This creates a Release (rather than a Debug) version of your app. The resulting files are placed in a directory named publish that’s in a sub directory of your project’s bin directory. At this point, if we check the Release folder, we would expect to see an .exe file, double click on it and run the application, right? Wrong! What we’ll find in the Release folder is a .dll file, not an .exe. Why so?

As we said at the beginning, .NET Core is a cross platform framework and when we deploy the console application, it will by default deploy it in a way that is platform independent. Even if we see a .dll file, if we take all files and copy them to a Linux or Mac where we have .NET Core installed we will be able to use the command line tool specific to the platform and run the application as we did earlier. This is what Microsoft calls framework dependent deployment.

So can we still create an .exe file? The answer is “yes” and the so called self-contained deployment reminds us once again what .NET Core is all about. In order to deploy an executable version we also need to define the runtime identifier, or, in other words, to tell exactly on which platform we plan to execute the application. This is also done in the .csproj file and it looks like this:

[code language=”csharp” highlight=”5″]
<Project Sdk=”Microsoft.NET.Sdk”>
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<RuntimeIdentifiers>win10-x64;osx.10.11-x64</RuntimeIdentifiers>
</PropertyGroup>
</Project>
[/code]

This

[code]<RuntimeIdentifiers>[/code]

tag indicates that the app runs on 64-bit Windows 10 operating systems and the 64-bit OS X Version 10.11 operating system. Before publishing the application, make sure that you save all changes and run once again

[code]dotnet restore[/code]

You may also want to execute the

[code]dotnet build[/code]

command to create a debug version first.

Regarding the deployment, we would need to deploy the application twice, both for Windows 10 and Mac OS. To proceed with the self-contained deployment, run the following commands:

[code]

dotnet publish -c Release -r win10-x64

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

[/code]

This creates a Release (rather than a Debug) version of your app for each target platform. The resulting files are placed in a subdirectory named publish that’s in a subdirectory of your project’s .\bin\Release\netcoreapp2.0<runtime_identifier> subdirectory. Note that each subdirectory contains the complete set of files (both your app files and all .NET Core files) needed to launch your app.

FDD vs. SCD

We have seen that we can deploy a .NET Core application using the default framework dependent deployment (FDD) process or the self-contained deployment (SCD) process. What is the best approach? The answer is: there isn’t a best approach. It really depends on your deployment strategy. If you choose FDD, then you need to be confident that on the target machine there is .NET Core installed. The application package is smaller and straight forward. If you’re not sure if .NET Core is installed, then you can use the SCD process. If you go this way, the .NET Core binaries are included in the release version of the application. When playing around with console applications, this might not be important. But if we think of an ASP.NET Core production application, SCD might be a good approach in case your hoster doesn’t support .NET Core out of the box. True, for really big and important applications we might use Azure AppService or IaaS containers or other technologies the fit best and probably we won’t need to deploy the application using command line.

I think that all this information put together might be however useful to understand better what .NET Core is and how it’s supposed to work, even if we’ll probably never deploy a production application using command line. Feedback is, as always, very valuable and if you really found time to read to the end, I would be glad if you could spend two more minutes to write a comment. Till the next time!

Cheers