Article

Converting a .NET application to .NET Core (formerly DNX)

June 4, 2016
Linux .NET
Andrew Male

In my first .NET core post, I set out on a journey to conquer the new world of .NET Core (formerly DNX) on Red Hat Enterprise Linux (RHEL). In my ignorance I believed I would do a short post on firing up RHEL, installing .NET Core, and then converting an application from .NET to .NET Core before adding it as a build job to a new TeamCity instance. The best laid plans seem to be the ones that get me closest to throwing my computer out the window, and Part 1 stands as a comedy of my errors. With all of that sorted, however, it is time to finish the job and start working with .NET Core on RHEL. (RHEL is now available at no cost for developer use! You can download it here.)

The Goals (A Review)

Just to go over our goals one more time...

  • 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

My Project

I spent some time deciding what project I would try converting to .NET Core, hoping to strike a balance between something with more than a ‘Hello, World’ output, but not so complex as to be an entire application. My search ended with an experimental C# library I began working on a year ago and neglected to finish. The framework has been partially constructed in three different languages (C#, PHP, and C++), and was put together enough that I could see if building it as a library was reasonable with .NET Core.

Step 1: The project.json File

The theory behind .NET Core is that you shouldn’t have to do too much to convert a project. Plop down a project.json file, run the dotnet restore and dotnet run commands, and in a perfect world, you should be finished. Fresh off my battle with setting up .NET Core, I dove in and grabbed the project.json from the “hello” project, and placed it inside the root directory of my framework’s C# folder.

Step 2: Restore/Run

Thanks to my work in part 1, the ‘restore’ command worked beautifully. All of the dependencies I didn’t realize I required were pulled onto the machine via NuGet and made available to the project. The ‘run’ command wasn’t as uneventful. ‘Run’ presented me with a few errors, mostly pointing to my use of the Environment.OSVersion property.

Step 3: Code Adjustments

One of the more frustrating parts of the process was dealing with the problem of missing Environment.OSVersion. It took a bit of searching to find a relevant issue on the dotnet core GitHub. The issue explains their decision to remove the property and its enumerations (it seems they feel that targeting specific versions of operating systems is a bad idea). I can’t say how many instances of this type of breaking change there are or will be with .NET Core, but hopefully, moving forward, they are well documented for people looking to move their codebases into .NET Core.

Regardless, thanks to the issue, I then had an idea of the problem and could devise a solution. For this framework, the purpose of the OSVersion usage was simply to help determine if the code was running on Windows or not, so I chose to replace the property with simply comparing the DirectorySeparatorChar against the typical Windows value (“\”) to make the determination.

Step 4: A project.json Adjustment

Now that I’d sorted the codebase to not use the missing property, I tried the dotnet run command again, only to be greeted with a new compilation error: 

error CS5001: Program does not contain a static 'Main' method suitable for an entry point

Thankfully this made more sense to me, and I realized the “hello” application I’d copied the project.json from was actually intended to create an executable, whereas this project was meant to be a library (dll). I went back into the project.json and immediately noticed the following line: 

“emitEntryPoint”: true

Without even looking, I figured it was worth giving a try, and changed the value to be false. Another attempt at ‘run’ produced a successful build (albeit with warnings from my incomplete code).

Step 5: Install TeamCity and Make a Build Job

At this point, I had finally overcome my relearning jitters. I was able to easily go through the TeamCity installation:

All that remained was to create a build job that would call dotnet restore and dotnet run whenever an update was pushed to the master branch of my framework’s repository. To say it was refreshing to have these final parts go smoothly is an understatement.

Conclusion

It was a much longer and tougher process than I think I’d imagined, but the satisfaction gained from making it through and achieving my goals was reward enough. As I stated before, I hope (and am quite sure) that more documentation will be added while .NET Core matures to help catch things such as my OSVersion misstep. Still, the system shows a lot of promise for helping teams expand their capabilities into the Linux/BSD world without having to do a complete rebuild of their codebase.

Caveat

I purposefully left out information regarding the way I made things like TeamCity available to run on my VM. I am aware of how little I know with regard to securing a Linux system, so I find it hard to believe I came even close to following appropriate procedure when installing TeamCity, Java, and even .NET Core. Be careful of these things the way you would anything else. Making them available to the world likely provides bad consequences.

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

Andrew 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: September 3, 2019

Comments