What’s ASP.NET Core?
ASP.NET Core is basically a revamped version of the good old ASP.NET Framework that developers have been using for quite a while now. One of they key features that Microsoft wants out if this new version is being able to create your applications from anywhere you want, making the Framework cross-platform and open source. For this, Microsoft not only created ASP.NET Core, but also included a new IDE (Visual Studio Code) for non-Windows users to play with, which you can check out over here.
Why All of this Changes Now?
One of the biggest challenges Microsoft had when confronting the competition on web development (Ruby, Java, Python and more) was that in order to use the Framework you would have to be a Windows user, this is itself made it a losing battle from start and was causing other options to gain increased popularity over the last few years.
This limitation was impacting on several other different levels as well, one of the most prominent one is Startups. Insanely huge businesses have being created out of a Startup as of late and pretty much all of the them use some of the open source technologies available today, which was sending the message that proprietary software was not required to scale your business needs and that it could all be done using open source solutions which in turned was hurting the popularity and usage of the ASP.NET Framework on the web.
This issues coupled with a thirst for innovation and improved development tools are the reason ASP.NET Core exists today, everything about this new release was build having this key concepts in mind at all steps of the way:
- Cross-Platform
- Open Source and Free
- Modular, Fast and Easily Extensible
- Community Focused
What Really Changed?
As we mentioned before, ASP.NET Core is truly portable, but for this change to happen Microsoft not only modified the ASP.NET Framework itself but also created a completely new CLR, this new CLR is the one in charge of building and running ASP.NET Core applications on a Mac or Linux if required.
Another big change is the fact that modularity and dependency injection are first class citizens of the Framework now, so the old System.Web namespace, for example, is now completely gone for all new applications created with ASP.NET Core. Every feature that wants to be included on your solution has being refactored into a NuGet package. This new approach allows developers to have complete control over exactly what goes into their solution. All of this allows for final solutions to be significantly smaller in size than what were were used to, and this includes a bunch of other benefits like being able to have better control of the overall security of you application, a significant boost in overall performance and also allows cloud hosted application to fit better on the pay-for-what-you-use model.
For everyone interested in taking a look at all that ASP.NET Core has to offer here is the official documentation, in there you will find all of the details for every topic discussed on this blog.
Understanding a base ASP.NET Core Application
Before we even begin, let’s take a moment to just list all the tooling I’m using at the moment of writing this post.
And that’s basically it :). Let’s get started!
Creating a .NET Core Web App.
There are two really simple ways to start with your new web application, you can use the common way and create it through the Visual Studio IDE as a New Project and selecting the .NET Core Web App Template.
After the selection, developers can choose one of three simple templates to start your development from, you can either choose an Empty Solution or you can choose from a Web API template or Web Application template, the difference between them is mostly that Web APIs are geared a little bit more towards building RESTful services that return raw data through HTTP and Web Applications are also able to return HTML as views to be rendered on the client.
Another way in which ASP.NET Core web apps can be bootstrapped is using the CLI tools installed by default with VS 2017. After installation users can simply go to the desired folder in which to start the solution and create a new one using the following commands:
$ dotnet new
$ dotnet restore
$ dotnet run
dotnet new will get us our base files required including a file which contains the base dependencies on our project, once we get there we can use dotnet restore to download all of those dependencies to our local solution and finally with the dotnet run we can built the solution and run the sample application. If you want more detail information about the CLI tools and how to use them feel free to check it out.
Base Solution Files
After opening our solution, we can see that the project does not contain a lot of files, we will be taken a brief look at each of the most important ones and what they represent for the application. I’ll also leave link to every topic that I think deserves a deeper look than what I’ll cover on this post.
Program.cs
In its most basic form, ASP.NET Core apps are just simple console applications, we can see the traditional Main method being used to create a new instance of a web application host using the WebHostBuilder, this builder also provides ways in which we can specify different settings on our host like the desired web server to be used (Kestrel on our case) or which class should be used as the app Startup. The builder exposes a series of different configuration options that we can modify to create exactly the host required for our application, additional settings that can be configured include selecting the content root directory for our application or setting the application Environment. There is a lot more to know about web hosts and their role on ASP.NET Core applications and you can read all about it from the official Microsoft documentation.
Startup.cs
There are two main things that have to happen here, the Startup class of our application, which we configured when building the app host, is the one in charge of defining exactly how we want the Request Pipeline to handle all the incoming HTTP requests, it is also on this class that we will set up the configuration for all the Services that our application depends on.
This class must always includes a Configure and ConfigureServices methods. The Configure method is where we will be specifying just exactly how our application will respond to incoming HTTP requests. We do this by injecting different middleware component to an IApplicationBuilder instance that is provided to us with Dependency Injection.
The IApplicationBuilder exposes a series of extension methods that we can use to configure each component that will try and handle the request and, if not successful, will pass it along to the next piece of middleware until it can finally process the request and generate a response back to the client.
On the other hand, the ConfigureService, which is optional, always runs before the Configure on application startup, this is the method that we will use to configure all of the additional Services that we will want available for Dependency Injection throughout our app. It is on this method that we can add Entity Framework or MVC to our application and configure it accordingly. All services added in here will be available on all the application using DI and they have to be added to the IServiceCollection that we have on the ConfigureServices method.
Middleware
Basically Middleware refers to all the software that is in charge of handling all requests done to the application and also for returning the corresponding response back to the client. It is assembled for .NET Core application using Middleware components, they each have and order in which they receive the request and after running it through some logic it can either choose to pass the request to the next component or cut the chain there and return a response back, a perfect example for this happens when we implement and authentication middleware component, each request passes into the component and after deciding if the request has the required authentication it can pass it to the next component or return an error back to the client. The order in which the component is called is configured in the Configure method mentioned before and it’s critical for the application’s security and overall performance and functionality.
.NET Core already provides a selection of built in Middleware component and developers can also choose to implement their own according to their specific needs, some of the already built in components include:
Exception Handling
So how do we handle errors that can happen on our application on this new framework? .NET Core comes with a build in way to easily catch any exception and act accordingly called the Developer Exception Page. This new way can be access on the Startup.cs class on the Configure method, it is a new functionality that displays all exception details on the client if an error occurs. Always remember to enable this only for development environments as displaying error information to final users is never a good practice.
The other alternative for displaying users only that an error occurred on a styled and pretty page is to use the UseExceptionHandler method on the ApplicationBuilder instance, on the example above if the application is running on Development Environment it will catch any exception and display the Exception Page that allows us to try and figure out exactly what went wrong, but once the app is not on Development anymore it will instead return the Error View on the Home Controller which can just be a simple HTML page that display user friendly information about the issue that happen instead of showing exception details.
Where to go from here?
Although the information presented here is barely scratching the surface on everything there is to know about .NET Core and all it’s changes I tried to include all the required basics to be able to understand how a new .NET Core app works, as always is up to every developer to take the next step in truly understanding the framework that they use or plan to use for their applications. There is a lot of changes from the way our apps used to work and it is a good idea to try and start understanding all of this differences as it looks like .NET Core is the future Microsoft is aiming at, regular ASP.NET applications will still be supported for a really long time but innovation is the name of the game when talking about web applications.
There is really a lot of information available online, here are some suggested places that you can use to start learning .Net Core today!
