This article is part of a series about .NET Core and how it is now as easy and efficient as any other stack like Node or Rails to create modern applications. .NET Core is sexy and you should know it .NET Core is sexy — Command Line Application .NET Core is sexy — Building a Web API

I always thought my first blog post would be a detailed tutorial about a serverless platform with multiple services, deployed using a single command line on AWS using GitLab CI. Or even a post praising the benefits of a Dungeons and Dragons (D&D) game between friends or workmates.

I was so innocent…

A couple of days ago I heard by chance that some recruitment agencies and firms specializing in developers refuse, on principle, any candidates or companies wishing to work with .NET, for the following reasons:

It is an old closed and proprietary ecosystem, completely opposed to other, sexier, development platforms which are much more agile and open, like NodeJS or RubyRails. A little like Java actually. But Java, not being supported by the evil Microsoft, is still tolerated in these same agencies and firms.

Meanwhile I’m developing web apps using C# and .NET Core on my personal MacBook, which I deploy using GitLab on AWS using Lambdas functions, Linux EC2 and Docker containers. I’ve even pushed some code and tests on the official open source Github repository, 5 years ago, which are still on it.

Needless to say I started to feel uncomfortable hearing this. Then I had a feeling of déjà-vu from discussing another of my passions: D&D, and hearing Role Playing Games are elitist with a bad reputation and which are very inaccessible. But I’ll talk about D&D another time.

So here I am, climbing onto my most noble warhorse, putting on my shiniest armor and setting off on a quest, not to the defense of the widow and the orphan, but to the support of the .NET Core platform’s reputation, with the goal of convincing you that we can easily and quickly develop in C# and .NET Core, as we can do in JavaScript and NodeJS.

What is the .NET Core platform?

Things can quickly become rather obscure when we talk about the .NET Core platform, so I’ll just quote the official documentation:

The .NET Core runtime provides a type system, assembly loading, a garbage collector, native interop and other basic services. The .NET Core framework libraries provide primitive data types, app composition types and fundamental utilities.

The ASP.NET runtime offers a framework for building modern cloud-based internet-connected applications, such as web apps, IoT apps and mobile backends.

The .NET Core CLI tools and language compilers (Roslyn and F#) enable the .NET Core developer experience.

The dotnet tool is used to launch .NET Core apps and CLI tools. It selects and hosts the runtime, provides an assembly loading policy and launches apps and tools.

In summary of the above:

The runtime enables execution of .NET Core binaries.

ASP.NET Core is a framework and a set of libraries which are ready to use to build web apps and APIs.

.NET Core CLI is like other platform CLIs, as it allows you to create, build, publish, setup and scaffold your projects, among other actions.

Let’s code!

Enough chit-chat. My objectives here are to show you how quick and easy it is to start working with .NET Core to create applications and websites, just as it would be using NodeJS or RubyRails −so let’s go.

Linux installation is quite simple; just follow this link and choose your distribution. About three or four commands are needed to register the Microsoft key and feed to install the necessary packages.

On Ubuntu, here is how it looks from the terminal:

Check the last SDK version during installation, which at the time of writing happens to be version 2.2.

Of course, you only need to do this once, and from thereon a simple command will confirm that all is working well:

dotnet --version

> 2.2.300

Installation on MacOs or Windows is even simpler: just download it from the official Microsoft portal and let the installer do the job for you. It should only take a couple of minutes.

Hello World!

In following a well-known ritual, let’s create a console application with the sole purpose to display Hello World!.

For impatient readers, here is the Git repository:

First create a new folder, then initialize your project from it:

mkdir hello-world

cd hello-world

dotnet new console

You will have the following files and folders:

hello-world

├── bin

├── obj

├── hello-world.csproj

├── Program.cs

You can already ignore the bin and obj folders, which are only there for build and debug steps, so you’ll never have to look into them. In fact, I ignore them both on VSCode and Git.

The .csproj file contains information about the runtime, packages, versions and other project configuration properties. It’s really small by default.

And finally, our most important file: Program.cs.

Here again, nothing is tricky − you have your default namespace. A class in which you declare your main entry point via the static method Main(). The class or namespace can be changed to whatever you want and does not need to be public, nor does the Main method. Here the class is internal, and the method is private.

The only constraint is to have at least this static Main method. Even the parameters are optional, but they exist to provide access to arguments through the command line execution.

Now, let’s run the application:

dotnet run

> Hello World!

It’s as easy as that. To get a release version of the application which is deployable on any environment having the .NET Core runtime (version 2.2 here), simply publish the application as follows:

dotnet publish -c Release -o dist

The resulting dist folder should appear like this:

dist

├── hello-world.deps.json

├── hello-world.dll

├── hello-world.pdb

├── hello-world.runtimeconfig.json

The hello-world.pdb can be deleted without issue as it’s only useful for debugging purposes but is generated by default, even in release mode. You can disable this behavior by adding this snippet to your hello-world.csproj (under the <Project /> tag).

Then hello-world.dll is your compiled code, executable using this runtime command:

dotnet hello-world.dll

The deps.json and runtimeconfig.json files are in place to handle dependencies on other packages and to configure the runtime, respectively.

Finally, you could just as easily target the build for a specific platform when publishing the application, using the Runtime Identifier Catalog:

dotnet publish -c Release -r win-x64 -o dist/win-x64

dotnet publish -c Release -r osx-x64 -o dist/osx-x64

dotnet publish -c Release -r linux-x64 -o dist/linux-x64

Hello Web !

Ok that’s cool, we wrote a line on the console pretty easily, but what about some web stuff ? Fine, that’s also very easy to do !

First, let’s add the package for ASP.NET Core:

dotnet add package Microsoft.AspNetCore

This package will allow us to Configure, Build and Run a simple WebHost. This can be done in a single line of code, in the Main() method. You’ll also need to reference the new package, just like you would import npm packages for NodeJS. The resulting Program.cs should look as follows:

You can use the same commands as above to run and build the app:

dotnet run

Now open your favorite browser, go to http://localhost:5000, and enjoy this wonderful Hello World! web page:

It’s alive!

That’s all for now. I’ll return with some more real-world examples, but after reading this I really hope your opinion about .NET Core has evolved.

If you have any questions, I’ll do my best to be as responsive as possible in the comments!

UPDATE: You can now continue with a real world example here thanks to my next story .NET Core is sexy — Real-world Part 1: Command Line Application.