In February 2017, the Manning Early Access Program (MEAP) started for the ASP.NET Core book I am currently writing - ASP.NET Core in Action. This post gives you a sample of what you can find in the book. If you like what you see, please take a look - for now you can even get a 37% discount with the code lockaspdotnet!

The Manning Early Access Program provides you full access to books as they are written, You get the chapters as they are produced, plus the finished eBook as soon as it’s ready, and the paper book long before it's in bookstores. You can also interact with the author (me!) on the forums to provide feedback as the book is being written.

When to choose ASP.NET Core

I’m going to assume that you’ve a general grasp of what ASP.NET Core is and how it was designed, but the question remains – should you use it? Microsoft is heavily promoting ASP.NET Core as their web framework of choice for the foreseeable future, but switching to or learning a new web stack is a big task for any developer or company. This article describes some of the highlights of ASP.NET Core and gives advice on the type of applications to build with it, as well as the type of applications to avoid.

What type of applications can you build?

ASP.NET Core provides a generalised web framework that can be used in a wide variety of applications. It can most obviously be used for building rich, dynamic websites, whether they are e-commerce sites, content-based websites, or n-tier applications – much the same as the previous version of ASP.NET.

A small number of third-party helper libraries are available for building this sort of complex application, but many are under active development. Many developers are working to port their libraries to work with ASP.NET Core – but it’ll take time for more to become available. For example, the open-source content management system (CMS) Orchard (figure 1) is currently available as an alpha version of Orchard 2, running on ASP.NET Core and .NET Core.

Figure 1. The ASP.NET Community blogs website (https://weblogs.asp.net) is built using the Orchard CMS. Orchard 2 is available as a pre-alpha version for ASP.NET Core development

Traditional, server-side rendered web applications are the bread and butter of ASP.NET development, both with the previous version of ASP.NET and ASP.NET Core. Additionally, single page applications (SPAs), which use a client-side framework that talks to a REST server, are easy to create with ASP.NET Core. Whether you’re using Angular, Ember, React, or some other client-side framework, it’s easy to create an ASP.NET Core application to act as the server-side API.

DEFINITION REST stands for Representational State Transfer. RESTful applications typically use lightweight and stateless HTTP calls to read, post (create/update), and delete data.

ASP.NET Core isn’t restricted to creating RESTful services. It’s also easy to create a web-service or remote procedure call (RPC)-style service for your application, depending on your requirements, as shown in figure 2. In the simplest case, your application might expose only a single endpoint, narrowing its scope to become a microservice. ASP.NET Core is perfectly designed for building simple services thanks to its cross-platform support and lightweight design.

Figure 2. ASP.NET Core can act as the server side application for a variety of different clients. It can serve HTML pages for traditional web applications, act as a REST API for client-side SPA applications, or act as an ad-hoc RPC service for client applications.

You must consider multiple factors when choosing a platform, not all of which are technical. One example is the level of support you can expect to receive from the creators. For some organizations, this can be one of the main obstacles to adopting open-source software. Luckily, Microsoft has pledged to provide full support for each major and minor point release of the ASP.NET Core framework for three years. Furthermore, as all development takes place in the open, you can sometimes get answers to your questions from the general community, as well as from Microsoft directly.

Two primary dimensions you must consider when deciding whether to use ASP.NET Core are: whether you’re already a .NET developer (or not); and whether you’re creating a new application or looking to convert an existing one.

If you’re new to .NET development

If you’re new to .NET development, and are considering ASP.NET Core, welcome! Microsoft is pushing ASP.NET Core as an attractive option for web development beginners, but taking .NET cross-platform means it’s competing with many other frameworks on their own turf. ASP.NET Core has many selling points when compared to other cross-platform web frameworks:

It’s a modern but stable web framework.

It uses familiar design-patterns and paradigms.

C# is a great language

You can build and run on any platform

ASP.NET Core is a re-imagining of the ASP.NET framework, built with modern software design principles on top of the new .NET Core platform. .NET Core is new in one sense, but has drawn significantly from the mature, stable, and reliable .NET Framework, which has been used for well over a decade. You can rest easy choosing ASP.NET Core and .NET Core because you’ll be getting a dependable platform, as well as a fully featured web framework.

Many of the web frameworks available today use similar, well-established design patterns, and ASP.NET Core is no different. For example, Ruby on Rails is known for its use of the Model-View-Controller (MVC) pattern; node.js is known for the way it processes requests using small discrete modules (called a pipeline); and dependency injection is found in a wide variety of frameworks. If these techniques are familiar, it’s easy to transfer them across to ASP.NET Core; if they’re new to you, you can look forward to using industry best practices!

The primary language of .NET development and ASP.NET Core is C#. This language has a huge following, and for good reason! As an object-oriented C-based language it provides a sense of familiarity to those familiar with C, Java, and many other languages. In addition, it has many powerful features, such as Language Integrated Query (LINQ), closures, and asynchronous programming constructs. The C# language is also designed in the open on GitHub, as is Microsoft’s C# compiler, code-named Roslyn [^1].

NOTE If you wish to learn C#, I recommend picking up C# in Depth by Jon Skeet, also published by Manning (ISBN 9781617291340).

One of the major selling points of ASP.NET Core and .NET Core is the ability to develop and run on any platform. Whether you’re using a Mac, Windows, or Linux, you can run the same ASP.NET Core apps and develop across multiple environments. As a Linux user, a wide range of distributions are supported (RHEL, Ubuntu, Debian, CentOS, Fedora and openSUSE, to name a few), and you can be confident that your operating system of choice will be a viable option. Work is underway to enable ASP.NET Core to run on the tiny Alpine distribution, for truly compact deployments to containers.

Built with containers in mind

Traditionally, web applications were deployed directly to a server, or in more recent years, to a virtual machine. Virtual machines allow operating systems to be installed in a layer of virtual hardware, abstracting away the underlying hardware. This has advantages over direct installation, like easy maintenance, deployment, and recovery. Unfortunately, they’re also heavy on file size and resource utilisation.

This is where containers come in. Containers are far more lightweight and don’t have the overhead of virtual machines. They’re built in a series of layers and don’t require you to boot a new operating system when starting. That means they’re quick to start and great for quick provision. Containers and Docker are quickly becoming the go-to platform for building large, scalable systems.

Containers have never been an attractive option for ASP.NET applications, but with ASP.NET Core, .NET Core and Docker for Windows, it’s all changing. A lightweight ASP.NET Core application running on the cross-platform .NET Core framework is perfect for thin container deployments.

As well as running on each platform, one of the selling points of .NET is the ability to only need to write and compile once. Your application is compiled to Intermediate Language (IL) code, which is a platform independent format. If a target system has the .NET Core platform installed, you can run compiled IL from any platform. That means you can, for example, develop on a MacBook or a Windows machine, and deploy the exact same files to your production Linux machines. This compile-once run-anywhere promise has finally been realized with ASP.NET Core and .NET Core.

If you’re a .NET Framework developer creating a new application

If you’re currently a .NET developer, then the choice of whether to invest in ASP.NET Core for new applications is a question of timing. Microsoft has pledged to provide continued support for the older ASP.NET framework, but it’s clear their focus is primarily on the newer ASP.NET Core framework. In the long-term, if you wish to take advantage of new features and capabilities, it’s likely that ASP.NET Core will be the route to take.

Whether ASP.NET Core is right for you now largely depends on your requirements, and your comfort with using products that are early in their lifecycle. The main benefits over the previous ASP.NET framework are:

Cross-platform development and deployment

A focus on performance as a feature

A simplified hosting model

Faster releases

Open-source

Modular features

As a .NET developer, if you aren’t using any Windows-specific constructs, such as the Registry, then the ability to build and deploy applications cross-platform opens the door to a whole new avenue of applications. Take advantage of cheaper Linux VM hosting in the cloud; use Docker containers for repeatable continuous integration; or write .NET code on your MacBook without needing to run a Windows virtual machine. ASP.NET Core in combination with .NET Core makes all this possible.

It’s important to be aware of the limitations of cross-platform applications - not all of the .NET Framework APIs are available in .NET Core. It’s likely that most of the APIs you need will make their way to .NET Core over time, but it’s an important point to note. The hosting model for the previous ASP.NET framework was a relatively complex one, relying on Windows Internet Information Services (IIS) to provide the web server hosting. In cross-platform environments this kind of symbiotic relationship isn’t possible, and an alternative hosting model has been adopted, which separates web applications from the underlying host. This opportunity has led to the development of Kestrel, a fast cross-platform HTTP server on which ASP.NET Core can run.

Instead of the previous design, whereby IIS calls into specific points of your application, ASP.NET Core applications are a form of console application, which self-hosts a web server and handles requests directly, as shown in figure 3. This hosting model is conceptually much simpler, and allows you to test and debug your applications from the command line, though it doesn’t remove the need to run IIS (or equivalent) in production.

Figure 3. The difference in hosting models between ASP.NET (top) and ASP.NET Core (bottom). With the previous version of ASP.NET, IIS is tightly coupled to the application, calling into specific exposed methods for different stages of a request. The hosting model in ASP.NET Core is simpler; IIS hands off the request to a self-hosted web server in the ASP.NET Core application and receives the response, but has no deeper knowledge of the application.

Changing the hosting model to use a built-in HTTP web server has created another opportunity. Performance has been a sore point for ASP.NET applications in the past. It’s possible to build highly performant applications – Stack Overflow (http://stackoverflow.com) is testament to that – but the web framework itself isn’t designed with performance as a priority, and can end up being somewhat of an obstacle.

To be competitive cross-platform, the ASP.NET team recently focused on making the Kestrel HTTP server as fast as possible. TechEmpower (www.techempower.com/benchmarks) have been running benchmarks on a whole range of web frameworks from various languages for several years now. In round thirteen of the plaintext benchmarks, TechEmpower announced that ASP.NET Core with Kestrel was now the fastest mainstream fullstack web framework, and among the top ten fastest of all frameworks!

Web servers – naming things is hard

One of the difficult aspects of programing for the web these days is the confusing array of, often conflicting, terminology. For example, if you’ve used IIS in the past you may have described it as a web server, or possibly a web host. Conversely, if you’ve ever built an application using node.js, you may have also referred to that application as a web server. Alternatively, you may have called the physical machines on which your application runs a web server!

Similarly, you may have built an application for the Internet and called it a website or a web application, probably somewhat arbitrarily based on the level of dynamism it displayed.

In this article when I say “web server” in the context of ASP.NET Core, I’m referring to the HTTP server that runs as a part of your ASP.NET Core application. By default, this is the Kestrel web server, but it’s not a requirement. It’d be possible to write a replacement web server and substitute it for Kestrel if you desired.

The web server is responsible for receiving HTTP requests and generating responses. In the previous version of ASP.NET, IIS took this role, but in ASP.NET Core, Kestrel is the web server.

I’ll only use the term web application for describing ASP.NET Core applications, regardless of whether they contain only static content or are completely dynamic. Either way, they’re applications that are accessed via the web, and that name seems appropriate!

Many of the performance improvements made to Kestrel didn’t come from the ASP.NET Team themselves, but from contributors to the open-source project on GitHub . Developing in the open means you should typically see fixes and features make their way to production faster than you would for the previous version of ASP.NET, which was dependent on the .NET Framework, and, as such, had long release-cycles.

In contrast ASP.NET Core is completely decoupled from the underlying .NET platform. The entire web framework is implemented as modular NuGet packages, which can be versioned and updated independently (from the underlying platform on which they are built).

NOTE NuGet is a package manager for .NET that enables importing libraries into your projects. It’s equivalent to Ruby Gems, npm for JavaScript, or Maven for Java.

To enable this, ASP.NET Core was designed to be highly modular, with as little coupling to other features as possible. This modularity lends itself to a pay-for-play approach to dependencies, whereby you start from a bare*bones application and only add the additional libraries you require, as opposed to the kitchen-sink approach of previous ASP.NET applications. Even MVC is an optional package! But don’t worry, this approach doesn’t mean that ASP.NET Core is lacking in features; it just means you need to opt-in those features. Some of the key infrastructure improvements include:

Middleware “pipeline” for defining your application’s behaviour

Built-in support for dependency injection

Combined UI (MVC) and API (Web API) infrastructure

Highly extensible configuration system

Scalable for cloud platforms by default using asynchronous programming

Each of these features was possible in the previous version of ASP.NET, but required a fair amount of additional work to setup. With ASP.NET Core, they’re all there, ready and waiting to be connected!

Microsoft fully supports ASP.NET Core, and if you’ve a new system you wish to build, there’s no significant reason not to. The largest obstacle you’re likely to come across is a third-party library holding you back, either because they only support older ASP.NET features, or they haven’t converted to work with .NET Core.

Converting an existing ASP.NET application to ASP.NET Core

In contrast to new applications, an existing application is presumably already providing value, and there should always be a tangible benefit to performing what may amount to a significant rewrite in converting from ASP.NET to ASP.NET Core. The advantages to adopting ASP.NET Core are much the same as for new applications; cross-platform deployment, modular features, and a focus on performance. Determining whether the benefits are sufficient depends largely on the particulars of your application, but some characteristics are clear indicators against conversion:

Your application uses ASP.NET Web Forms

Your application is built on Web Pages, WCF, SignalR, or VB.NET

Your application is large, with many “advanced” MVC features

If you’ve an ASP.NET Web Forms application, attempting to convert it to ASP.NET Core isn’t advisable. Web Forms is inextricably tied to System.Web.dll, which will likely never be available in ASP.NET Core. Converting an application to ASP.NET Core would effectively involve rewriting the application from scratch, not only shifting frameworks but also shifting design paradigms. A better approach would be to slowly introduce Web API concepts and try to reduce the reliance on legacy Web Forms constructs, such as ViewData. Numerous resources are online to help you with this approach, like the www.asp.net/web-api website.

Similarly, if your application makes heavy use of Web Pages or SignalR, then now may not be the time to consider an upgrade. These features are under active development (currently under the monikers “Controller-less Razor Pages” and “SignalR 2.0”), but haven’t been released as part of the ASP.NET Core framework. Similarly, VB.NET is pegged for future support, but currently isn’t part of the framework.

Windows Communication Foundation (WCF) is also currently not supported, but it’s possible to consume WCF services by jumping through some slightly obscure hoops. Currently there’s no way to host a WCF service from an ASP.NET Core application; if you need the features WCF provides, and can’t use a more conventional REST service, then ASP.NET Core is probably best avoided.

If your application is complex and makes use of the previous MVC extensibility points or message handlers, then porting your application to ASP.NET Core could prove complex. ASP.NET Core is built with many similar features to the previous version of ASP.NET MVC, but the underlying architecture is different. Several previous features don’t have direct replacements, and will require re-thinking.

The larger the application, the greater the difficulty you’re likely to have in converting to ASP.NET Core. Microsoft suggests that porting an application from ASP.NET MVC to ASP.NET Core is at least as big a rewrite as porting from ASP.NET Web Forms to ASP.NET MVC. If that doesn’t scare you then nothing will!

When should you port an application to ASP.NET Core? As I’ve discussed, the best opportunity for getting started is on small, green-field, new projects instead of existing applications. That said, if the application in question is small, with little custom behaviour, then porting might be a viable option. Small implies reduced risk, and probably reduced complexity. If your application consists primarily of MVC or Web API controllers and associated Razor views, then moving to ASP.NET Core may be feasible.

Summary

Hopefully this article has kindled your interest in using ASP.NET Core for building your new applications. For more information, download the free first chapter of ASP.NET Core in Action and see this Slideshare presentation. Don’t forget to save 37% with code lockaspdotnet at manning.com.

[^1]: C# language and .NET Compiler Platform GitHub source code repository (https://github.com/dotnet/roslyn)