Deploy a NET Core console application using command line

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:
dotnet new console

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:

using System;

namespace Core
    class Program
        static void Main(string[] args)

        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}, ");


Run the application

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

dotnet restore

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:

dotnet run

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:

dotnet publish -f netcoreapp2.0 -c Release

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

<Project Sdk="Microsoft.NET.Sdk">

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:

<Project Sdk="Microsoft.NET.Sdk">



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

dotnet restore

You may also want to execute the

dotnet build

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:

dotnet publish -c Release -r win10-x64

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

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.


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!



4 thoughts on “Deploy a NET Core console application using command line

  1. Hemant

    Nice Article. The point on SDD and FDD was useful as it put the usability into perspective.

  2. Carlos Adolfo Ortiz Quirós

    Thank you for writing this post. I am toying with .NET Core in Mac OSX and this helped me to know which deployment strategies there are. But one question arises. Do you know where I can find the list.

    Question: I need to know if it is possible to make a SCD for Windows Server 2012 R2 and above.

    Question: How do I know to which .NET Core SDK I am targeting, that is, how do I know which SDK I compile and deploy to.

    Question: I other machine has .NET Core V2.1 for instance, and I develop/compile/build for .NET Core V2.0, would it run there?

    1. Dan Patrascu-Baba Post author

      Hello. Thank you for commenting ans asking real good questions. I will try to respond based on my on trial and errors.

      1. You can do a SCD version for Windows Server 2012. Microsoft has a RuntimeIdentifier (RID) catalog where you can look up exactly what identifier you’ll need for a specific OS and you can find it here

      2. If you right click the project in Visual Studio and go to “Properties” you will find the target framework there. Alternatively you can find it in the .csproj file.

      3. Ideally the versions should always match. So what you target in your applications should also be installed on the server where you want to deploy the application. This is a scenario where SCD might be useful. On the other side .Net core should be backward compatible similarly to how the .Net Framework worked. Theoretically if you have a .Net Core 1.x application and .Net Core 2.0 on the server, it should work, except if you are using some .Net Core APIs that have breaking changes from one major version to another.

Leave a Reply

Your email address will not be published. Required fields are marked *