Despite spending plenty of time in Red Hat Linux while I was young, I have become an unabashed Windows environment super-user/programmer. Still, it’s hard to discount the multitude of ways that the *nix community stands ahead and alone, so when Microsoft and Red Hat announced their partnership to bring .NET to Linux, I had no choice but to take notice. As an experiment, I am going to go through setting up Red Hat Enterprise Linux (RHEL) and .NET Core to see if I can’t have a little fun and test the technology before it’s even at its first release.

This post is the first of two, with the final goal of learning how to convert an existing .NET application to .NET Core. But first we have to set up .NET Core on RHEL. (Also note that RHEL is now available at no cost for developer use! You can download it here.)

(Tip: if you want to go straight to the answer, skip to the third setup attempt)

The Goals

For this first post, the goals were meant to be straightforward:

  • Create a functioning VM on my local machine with RHEL 7.2 and Windows Hyper-V
  • Install Visual Studio Code
  • Install .NET Core
  • Convert a simple .NET project to work on .NET Core
  • Install TeamCity
  • Create a TeamCity Build Job for the .NET project

Setting up the VM (The First Time)

Deciding to get straight into it, I found my way to and followed the directions to get started with a Hyper-V install. Lo and behold, everything went swimmingly and I was up and running with a simple RHEL 7.2 VM almost accidentally. After correcting a minor issue with my network switch (I had selected the wrong adapter to pass the connection through, purely my mistake), I was able to easily install Visual Studio Code and got ready to dig into .NET Core.

.NET Core, RPMs, and Tragedy

In doing research for this effort, I’d found a post only a couple days old that seemed to cover the beginnings of my effort (I even started to worry I’d chosen a bad topic). Following the links there I downloaded the RPMs and allowed RHEL to install them for me via a series of double-clicks. All seemed well, I ran the scl enable command, and everything worked! Or so it seemed.

I was able to use the dotnet new and dotnet restore commands, but when I tried calling dotnet run to compile and execute the starter project, a crack appeared in the world. I was presented with a message describing a problem loading the host policy for the version of .NET Core I was attempting to run. I tried many things:

  • Manually adjusting versions in the project.json to match what I appeared to have on disk
  • Replacing the .NET Core binaries with those provided on GitHub
  • Installing multiple versions of the binaries alongside each other

All attempts proved fruitless, and I took a few minutes to belittle inanimate objects in my apartment as a vent for my (likely unreasonable) rage. It was time to try another tactic.

Setting up the VM (The Second Time)

With one set up under my belt, I was feeling more confident. Burr’s post also references pre-built VM’s for Hyper-V and VirtualBox, so it seemed a sure-fire solution to my problems. I erased all my previous work, created a new VM using the supplied vhdx, and settled in to get back to making progress.

The fates were against me, however, as for some reason (probably due to my own ineptitude), the VM refused to allow me to register the account underneath my Red Hat developer account. I found out that this is a significant problem on Red Hat, as it makes things such as yum inoperable.

Back to the drawing board.

Setting up the VM (The Third Time)

After a motivational talk and some Linux tips from a friend, I tore down the pre-built VM and started again from scratch. This time, however, I remembered that the best way to learn is to do it yourself. I followed the instructions in Don Schenck’s starter container kit, and off I went:

  1. Install RHEL 7.2, as in first attempt (no problems)
  2. Install VS Code (no problems)
  3. wget latest binaries in tar.gz format from GitHub
  4. Install dependencies (libicu, libuuid, libcurl, openssl, and libunwind)
  5. Extract dotnet files into a directory in my home
  6. Add the DOTNET_HOME path to my .bash_profile (reload with source ~/.bash_profile)
  7. Run example project commands (dotnet new, dotnet restore, dotnet run)

While running the dotnet restore, I ran into a problem where NuGet didn’t seem to know how to resolve any of my project’s dependencies (shown by the message Unable to resolve 'Microsoft.NETCore.App' for '.NETCoreApp,Version=v1.0'.). With some Google/Bing magic, I found an issue on GitHub that recommended I change my NuGet feed list in ~/.nuget/NuGet/NuGet.Config to use feeds from Making this change did fix my issue with restoring the project.

I also ran into a problem again with the referenced version of the Microsoft.NETCore.App dependency for the project (located inside the project.json). I resolved this by changing the value from “1.0.0-rc2-3002446” to the installed version (from Step #3) of “1.0.0-rc2-002446”.

It was only then that I was able to successfully compile and run the ‘Hello World!’ application that dotnet new creates for you.

Final Thoughts, And Part 2

First and foremost, I need to provide a disclaimer:

All of this work was done with a pre-release version of .NET Core, and it is not an accurate indicator of the final product. The Red Hat official "yum install dotnet" functionality is due any time now and will simplify things greatly.

It’s an important disclaimer because it means the pain and process I had to go through to get .NET Core (formerly DNX) running are unlikely to be necessary once the project stabilizes with 1.0. I look forward to that release, but for now I certainly relearned a good deal about Linux.

In Part 2 of this series, I’ll be going over how to convert an existing .NET application to .NET Core as well as setting up TeamCity to build that project automatically. Be sure to sign up for Red Hat Developers to stay in the loop for my next post!


Here is a grab bag of the various things that helped me get this far:

For additional information and articles on .NET Core visit our .NET Core web page for more on this topic.

Screen Shot 2016-05-27 at 4.01.34 PMAndrew Male

Andrew Male (@AndyM84) is a senior engineer at an enterprise development company in Boston, MA. Andrew has been programming from a young age and is entirely self-taught. He has spent time in many corners of the programming world, including game/VR work, agency work, and teaching development to students and adults alike. He spends most of his time working on architecture design and pursuing his favorite hobby—physics.

Last updated: March 15, 2023