One of the main reasons for using .NET Core is that you can run it on multiple platforms and architectures. So you can build an app that will run on Windows, but also on Linux, macOS and on different architectures like x86 and ARM. This is perfect for lots of scenarios, including desktop applications.
You can learn about other reasons for using .NET Core in this article about the .NET ecosystem on Stackify’s blog and in my Pluralsight course: The .NET Ecosystem: The Big Picture.
In this article, I’m going to show you how to create a simple .NET Core console application that can run on multiple operating systems.
To work through the demos in this article, make sure that you have the following installed on a computer running Windows 10:
Additionally, in order to run the app on a Mac, you will need access to a Mac that is running macOS 10.12 “Sierra” or a later version. If you don’t have one, you can get access to a Mac environment using https://www.macincloud.com
You can deploy .NET Core applications as framework-dependent applications and as self-contained applications.
There are a couple of differences between the two deployment models:
Now that we know there are two different deployment options for .NET Core, let’s explore how to use those to run a .NET Core app in multiple operating systems.
To explore this, we’ll create two simple .NET Core console applications and run those on Windows and on macOS. I’ve already created this sample in a GitHub repository that you can find here.
We’ll create the applications using Visual Studio 2017. This is technically not needed, as you can create .NET Core applications with many different IDEs and even with the command line. Choose the IDE or tool that you are most comfortable with.
Framework-dependent app
First, we’ll create a framework-dependent app. We do this in Visual Studio 2017 with all the latest updates (at the moment, I’m on 15.5.2).
That’s it! This app will run on every operating system that .NET Core supports.
Self-contained app
Next, we’ll create a self-contained app. This is very similar to creating a framework-dependent app, but contains one extra step:
So now, we have two .NET Core console applications; one framework-dependent and one self-contained. Let’s run them on Windows and on macOS.
Publishing the applications to run on Windows
Before we run the apps, we need to publish them, as you would do in production, to get a release build. For Windows, we can follow the same steps for both applications:
Publishing for running on macOS
If we want the framework-dependent app to run on macOS, we don’t have to do anything special, we can just use the publish results of the previous steps.
However, if we want the self-contained app to run on anything other than Windows, we need to take additional steps:
The runtime identifier that we’ve just added was one of many that you can find in the .NET Core Runtime Identifier Catalogue here.
Running the applications on Windows
We now have the following publish results:
Let’s run them. First, we’ll run the framework-dependent application on Windows:
Now, let’s run the self-contained app. This is easier because it contains all of the bits necessary to run the application. This means that it has packaged the app and .NET Core, including dotnet.exe into a special executable that you just need to run.
Running the applications on macOS
Let’s see if we can get this to run on macOS as well. The process is very similar as the process on Windows. If you don’t have a Mac, but do want to try this out, you can access a Mac for a fee from https://www.macincloud.com
Now, let’s run the framework-dependent app on macOS:
Now to run the self-contained app on macOS:
One of the key differentiators of .NET Core is that you can use it to run an application on multiple platforms. This can be vital for your application.
It is very simple to create a framework-dependent app that can run on multiple platforms. In order to run, It only needs the .Net Core runtime to be installed.
Creating a completely self-contained application is also simple, you just need to add Runtime Identifiers and publish for a specific platform. This is because the publish for the specific platform results in platform-specific files. For Windows, it produces an .exe file with all its dependencies, but for macOS, it produces a macOS executable file, which is very different and can’t run on Windows.
One thing that we didn’t discuss is that you can run into platform differences when you use platform-specific functionalities, like when you access the file system of the computer. You need to keep this in mind and create platform-specific implementations for these things.
With APM, server health metrics, and error log integration, improve your application performance with Stackify Retrace. Try your free two week trial today
If you would like to be a guest contributor to the Stackify blog please reach out to stackify@stackify.com