Common Core

Small and large web applications are becoming increasingly common in the enterprise. Many administrators program small tools to optimize existing system management, and Microsoft's .NET Core now makes this possible across operating system boundaries. In this article, I look at the part of the .NET Core functionality that enables the development and operation of dynamic web applications – ASP.NET Core – and its use on Linux, with a focus on the peculiarities of providing ASP.Net Core applications and not on their application logic or graphical design.

.NET Core Genesis

At the beginning of the century, Microsoft heralded a new era in their software development history with the announcement of the .NET Framework. A promise was made that the framework would not be exclusively reserved for the Windows platform. After all, the write once, run anywhere (WORA) principle was one of the factors that had already helped Java achieve great success as an enterprise platform.

Microsoft did not pursue the "Linux.NET" idea any further although several open source projects emerged to enable seamless porting of .NET applications to Linux and Unix. The best known and longest lasting of these projects was Mono, developed and maintained by the core team that later created Xamarin; however, Mono never achieved true feature parity with the official .NET.

The deep divide with Linux and open source seems to have largely been overcome at Microsoft. Xamarin is now also based in Redmond and the company's products have been incorporated into Visual Studio as components for the development of mobile applications. In view of this openness toward other platforms, the idea of extending the leading development framework to Linux, macOS, and potentially CPU architectures other than x64 and x86 was obvious.

Microsoft decided to redevelop the framework completely, with an open source and cross-platform design from the beginning. Not surprisingly, the manufacturer left out many Windows-specific frameworks that were docked to .NET in the course of development and concentrated on the core functionality – .NET Core was born. Many administrators first encountered the new .NET in the form of the PowerShell Core, which is also open source and available on many operating systems.

Web Apps as Servers

On the Internet Information Server (IIS), where ASP.NET is at home, the .NET code runs in application pools. The IIS web worker handles network communication with the client, TLS encryption, and authentication; the application pool receives "pre-processed" requests, processes them, and passes the results back to the web worker, which then makes it available to the browser.

.NET Core is based on a different architecture. Instead of being integrated into a web server as a kind of extension, as is the case with PHP or classic ASP, every web application under .NET Core is a full-fledged web server. It listens even to client requests and transmits the web content prepared by the .NET Core program code to the browser. This structure is not unlike its Java counterpart Tomcat. The .NET Core web server has been given the code name "Kestrel", which is also found in the object model of ASP.NET Core.

By the way, a compiled ASP.NET Core application is not portable, in that it still requires the .NET Core runtime on the target machine in the version against which the application was originally compiled. At the time of print, version 3.1 of the framework is up to date. All code examples in this article refer to that version. The successor version will be numbered 5 and is already available as a preview. Microsoft intends to merge the "original" .NET framework – which is currently also approaching version 5, at version 4.8 – with the open source .NET Core framework [1].

Creating an Initial App

The fastest way to get to know the Kestrel Worker is to install the .NET Core Software Development Kit (SDK) and create a sample app. On CentOS 8 and current Red Hat and Fedora versions, you can enter:

sudo dnf install dotnet-sdk-3.1

Installing on other supported Linux distributions is documented online [2]. If you are planning for production use, please note the rather strict Microsoft support guidelines. Once the SDK has been installed successfully, you can create and start a webapp in any directory from one of the numerous templates provided:

mkdir testwebapp
cd testwebapp
dotnet new mvc
dotnet run

If your Linux machine has a GUI, you can access the new website on https://localhost:5001 in your browser (Figure 1).

Figure 1: The test app is quickly created with the SDK and is ready to run immediately.

Of course, neither a GUI nor a complete .NET development environment will be installed on a production Linux web server. Before you can call the new test app from another machine, you still have to overcome some hurdles. First, in the default installation, Kestrel explicitly creates a binding to localhost. You can change this by adding the following line to the Program.cs file with the appropriate parameter:

webBuilder.UseStartup<Startup>().UseUrls(new[] { "https://*:4711" });

The Kestrel instance now listens on port 4711 on any IP address. The next hurdle is the local firewall of the Linux server. In most common distributions, it is activated and only lets SSH traffic through. You have to open the selected port to reach your new app:

sudo firewall-cmd --permanent--zone=public --add-port=4711/tcp
sudo firewall-cmd --reload