Getting started with .NET for Linux

Microsoft's decision to make .NET Core open source means it's time for Linux developers to get comfortable and start experimenting.
749 readers like this.
people on top of a connected globe

Pixabay

When you know a software developer's preferred operating system, you can often guess what programming language(s) they use. If they use Windows, the language list includes C#, JavaScript, and TypeScript. A few legacy devs may be using Visual Basic, and the bleeding-edge coders are dabbling in F#. Even though you can use Windows to develop in just about any language, most stick with the usuals.

If they use Linux, you get a list of open source projects: Go, Python, Ruby, Rails, Grails, Node.js, Haskell, Elixir, etc. It seems that as each new language—Kotlin, anyone?—is introduced, Linux picks up a new set of developers.

So leave it to Microsoft (Microsoft?!?) to throw a wrench into this theory by making the .NET framework, coined .NET Core, open source and available to run on any platform. Windows, Linux, MacOS, and even a television OS: Samsung's Tizen. Add in Microsoft's other .NET flavors, including Xamarin, and you can add the iOS and Android operating systems to the list. (Seriously? I can write a Visual Basic app to run on my TV? What strangeness is this?)

Given this situation, it's about time Linux developers get comfortable with .NET Core and start experimenting, perhaps even building production applications. Pretty soon you'll meet that person: "I use Linux … I write C# apps." Brace yourself: .NET is coming.

How to install .NET Core on Linux

The list of Linux distributions on which you can run .NET Core includes Red Hat Enterprise Linux (RHEL), Ubuntu, Debian, Fedora, CentOS, Oracle, and SUSE.

Each distribution has its own installation instructions. For example, consider Fedora 26:

Step 1: Add the dotnet product feed.

	sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
	sudo sh -c 'echo -e "[packages-microsoft-com-prod]\nname=packages-microsoft-com-prod \nbaseurl=https://packages.microsoft.com/yumrepos/microsoft-rhel7.3-prod\nenabled=1\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" > /etc/yum.repos.d/dotnetdev.repo'

Step 2: Install the .NET Core SDK.

	sudo dnf update
	sudo dnf install libunwind libicu compat-openssl10
	sudo dnf install dotnet-sdk-2.0.0

Creating the Hello World console app

Now that you have .NET Core installed, you can create the ubiquitous "Hello World" console application before learning more about .NET Core. After all, you're a developer: You want to create and run some code now. Fair enough; this is easy. Create a directory, move into it, create the code, and run it:

mkdir helloworld && cd helloworld
dotnet new console
dotnet run

You’ll see the following output:

$ dotnet run
Hello World!

What just happened?

Let's take what just happened and break it down. We know what the mkdir and cd did, but after that?

dotnew new console

As you no doubt have guessed, this created the "Hello World!" console app. The key things to note are: The project name matches the directory name (i.e., "helloworld"); the code was build using a template (console application); and the project's dependencies were automatically retrieved by the dotnet restore command, which pulls from nuget.org.

If you view the directory, you'll see these files were created:

Program.cs
helloworld.csproj

Program.cs is the C# console app code. Go ahead and take a look inside (you already did ... I know ... because you're a developer), and you'll see what's going on. It's all very simple.

Helloworld.csproj is the MSBuild-compatible project file. In this case there's not much to it. When you create a web service or website, the project file will take on a new level of significance.

dotnet run

This command did two things: It built the code, and it ran the newly built code. Whenever you invoke dotnet run, it will check to see if the *.csproj file has been altered and will run the dotnet restore command. It will also check to see if any source code has been altered and will, behind the scenes, run the dotnet build command which—you guessed it—builds the executable. Finally, it will run the executable.

Sort of.

Where is my executable?

Oh, it's right there. Just run which dotnet and you'll see (on RHEL): 

/opt/rh/rh-dotnet20/root/usr/bin/dotnet

That's your executable.

Sort of.

When you create a dotnet application, you're creating an assembly … a library … yes, you're creating a DLL. If you want to see what is created by the dotnet build command, take a peek at bin/Debug/netcoreapp2.0/. You'll see helloworld.dll, some JSON configuration files, and a helloworld.pdb (debug database) file. You can look at the JSON files to get some idea as to what they do (you already did … I know … because you're a developer).

When you run dotnet run, the process that runs is dotnet. That process, in turn, invokes your DLL file and it becomes your application.

It's portable

Here's where .NET Core really starts to depart from the Windows-only .NET Framework: The DLL you just created will run on any system that has .NET Core installed, whether it be Linux, Windows, or MacOS. It's portable. In fact, it is literally called a "portable application."

Forever alone

What if you want to distribute an application and don't want to ask the user to install .NET Core on their machine? (Asking that is sort of rude, right?) Again, .NET Core has the answer: the standalone application.

Creating a standalone application means you can distribute the application to any system and it will run, without the need to have .NET Core installed. This means a faster and easier installation. It also means you can have multiple applications running different versions of .NET Core on the same system. It also seems like it would be useful for, say, running a microservice inside a Linux container. Hmmm…

What's the catch?

Okay, there is a catch. For now. When you create a standalone application using the dotnet publish command, your DLL is placed into the target directory along with all of the .NET bits necessary to run your DLL. That is, you may see 50 files in the directory. This is going to change soon. An already-running-in-the-lab initiative, .NET Native, will soon be introduced with a future release of .NET Core. This will build one executable with all the bits included. It's just like when you are compiling in the Go language, where you specify the target platform and you get one executable; .NET will do that as well.

You do need to build once for each target, which only makes sense. You simply include a runtime identifier and build the code, like this example, which builds the release version for RHEL 7.x on a 64-bit processor:

dotnet publish -c Release -r rhel.7-x64

Web services, websites, and more

So much more is included with the .NET Core templates, including support for F# and Visual Basic. To get a starting list of available templates that are built into .NET Core, use the command dotnet new --help.

Hint: .NET Core templates can be created by third parties. To get an idea of some of these third-party templates, check out these templates, then let your mind start to wander…

Like most command-line utilities, contextual help is always at hand by using the --help command switch. Now that you've been introduced to .NET Core on Linux, the help function and a good web search engine are all you need to get rolling.

Other resources

Ready to learn more about .NET Core on Linux? Check out these resources:

User profile image.
A developer who has seen it all, Don is a Microsoft MVP and currently a Director of Developer Experience at Red Hat, with a focus on Microsoft .NET on Linux. His mission is to connect .NET developers with the Linux and open source communities. Prior to Red Hat, Don was a Developer Advocate at Rackspace where he was immersed in cloud technology.

11 Comments

Thank you for the very detailed article on developing .Net application on Linux. Although it's been more than year since the .Net Core was made available, the adoption is very less. I think the current generation of developers needs to be coached on building some open-source apps using C# for the .Net core runtime to increase the adoption. Need to explore the .Net Native. Can you shed some light on this new initiative?

Great introduction. It is exciting news and I didn't know about it's portability.

At work our Intranet is ASP.NET but our external sites are Linux so if this can help consolidate the different OSs that would be great. Combine with MS SQL Server on Linux and our reliance on Microsoft Windows gets reduced even further.

I'd love to see more on setting up a workflow for developing .NET on Linux (or even Windows and Visual Studio) and deploying to a server running Linux.

Drew -- Indeed, having MS SQL Server run on Red Hat Enterprise Linux (RHEL) is a huge plus. When you add in Linux containers and Kubernetes, it quickly becomes a .NET developer's dream: Fast, portable, containers, micro services ... all the goodies.

I have some stuff at RedHatLoves.net (my URL); your ask about .NET on Linux + Windows and deploying to a Linux server is something I've been "meaning to do" for quite some time -- that is, a blog post and video.

I'll see if I can buy some time during next week's holiday break and put it together. Thanks for the 'nudge'.

In reply to by dragonbite

What is the relationship or differences between .Net Core and Mono?

Get that question a lot.

Mono is the old, community-based *successful* attempt to port .NET Framework to Linux. Xamarin was (is) based on Mono, so when Microsoft purchased Xamarin, Mono came with it.

To be frank, .NET Core is much faster, since it was a new project and developers were/are able to take what was learned from previous attempts, i.e. .NET Framework.

In short, Mono <> Core.

NOTE, HOWEVER: .NET Standard 2.0 is huge here.

.NET Standard 2.0 is NOT a framework, but a _specification_. .NET Core 2.0, .NET Framework and Mono all adhere **to some level** to .NET Standard 2.0. The APIs described in .NET Standard 2.0 will work on ALL .NET choices: Core, Framework and Mono.

In other words; If you write code to the specifications in .NET Standard 2.0, you know it will run anywhere. Pretty cool, eh?

There is a nifty tool to check your existing libraries to see where rate regarding compatibility with all of the .NET versions. It's called APIPort and can be found here:

https://github.com/Microsoft/dotnet-apiport

Hope this helps.

I also *strongly* suggest checking out the URL RedHatLoves.net and also live.asp.net.

-- Don

In reply to by emiliosic

I don't know who this guy is, but I will tell any sane developer out there, don't listen to him. "Linux is a cancer that attaches itself in an intellectual property sense to everything it touches." from Steve Ballmer.

Micro$oft is trying to worm their grubby mitts in because they could not beat Linux, so, they try the Trojan Horse approach. And the powers that be at RedHat fell for, hook, line and sinker.

This guy, and his approach is dangerous to open source. He says "Get used to it, its coming. And he is correct, but Micro$oft is not your friend, or your ally. They will stab Linux in the back when its to late, and the so called open Source movement will cease to exist. The best defense is exactly what there are up to, which is no good. But they can't help it, they want to own the the world, and the scary thing is.... they will.

Beware of Micro$oft!

I'm going to have to disagree with this article. .NET is NOT a mandatory, feature that Open Source and Linux/Unix users need to "get used to" because "its coming"

Understand:

The open source community has existed for this long BECAUSE they don't live-or-die by Microsoft's hand. We don't have to "abide" by any of their rules because we create and abide by our own. The whole "Microsoft Loves Linux" motto isn't fooling the die-hard open source developers and supporters, nor will it ever permeate throughout the entire FOSS-sphere, because some folk actually PREFER to live a Windows-Free lifestyle. And its not a fanboy/fangirl thing....for these people, open source just fits their needs...their businesses....their personal computing lifestyles better, and they see no reason to muck it up with forays into Microsoft's confusing and (often times) license-plagued world. This is why the Open source community is so vibrant,...and plenteous. We exist from California to Cleveland, from Boston to Botswain.....from San Francisco to Sweden.....from Chicago to China....we've already gone "worldwide" and it disturbs Microsoft, (and Apple too!) because they're powerless to stop us. They've tried it all...from locking their kernels, to changing drivers mid-cycle, to creating the UEFI and ALL of their attempts have FAILED. Now why would I want to ditch C++...Python...Java and the like...to take up .NET? what value would that bring to me and all my open source projects? Nah....no thanks. This might be enticing to someone who hasn't been in the world of FOSS for long, and so....they don't know about the struggles...the battles that have ensued, but to the veterans?....heck to the CHILDREN of veterans?....they'll know and recognize mischievous behaviors when they spot it and will not want anything to do with it! Just my way of seeing things..

Came across this concept for the first time and understtod that .net applications can be run on linux platform. Thank you for sharing very helpful information.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.