This blog was co-written by Logan Helms.
We at CTS pride ourselves on being steps ahead of the curve when it comes to new technologies. As anyone in the world of technology knows however, software, tools, and frameworks are never static beings, so staying on our game can be a challenge.
With this in mind, we have decided to examine one of Microsoft’s latest offerings: ASP.NET Core. In this post we will talk about what ASP.NET Core is, as well as why it is something to be excited about, both for developers, as well as for CTS’s customers or potential customers. Beyond just talking about the differences, we used ASP.NET Core to create a very simple CRUD application called FancyRestaurant, a fictitious reservation app for the (also fictitious) Fancy Restaurant. Please review the code for this app here in order to gain helpful context for the concepts we will be discussing.
WHAT IS ASP.NET CORE?
ASP.NET Core is the next step and logical evolution of Microsoft’s ASP.NET framework. It is “a cross-platform, open source, and modular .NET platform for creating modern web apps, micro-services, libraries and console applications.” (Source: MSDN blog) At its core (pun definitely intended), ASP.NET Core seeks to do a few things:
- To exist as a cross-platform (Windows, Mac, Linux), open source framework. In fact, you can view the ASP.NET Core repository here.
- To combine ASP.NET MVC and ASP.NET Web API, and cut out ASP.NET Web Forms (support will still be offered, just not present in the ASP.NET Core framework)
- Opt-in dependency model, you opt-in only to the dependencies you need, rather than getting everything dropped in your lap. This significantly reduces overhead.
(Source: Shawn Wildermuth)
Furthermore, while System.Web.dll is the traditional basis for ASP.NET applications, in ASP.NET Core, applications rely on a set of granular NuGet packages. This allows a developer to bring in only the dependencies needed for a particular project.
ASP.NET Core was also born out of the realization that ASP.NET is blatantly showing its age, contains a plethora of unused code, and was approaching the zenith of its performance. The team working on the early versions of ASP.NET Core quickly realized that almost all other major web platforms were open source, and many seemed to be, or already were, on track to far outstrip the performance offered in ASP.NET. From this realization, ASP.NET Core was born.
Seeing Microsoft take a cross platform, open source approach is refreshing in its own right. While ASP.NET MVC was an open-source project, the framework backing it was not. However, in ASP.NET Core, everything is wide open for customization and tinkering!
With all of these core purposes in mind (I did it again!) we will now set out to test the waters with an in-house proof of concept, as well as learn a little bit about a cool new technology.
WHAT IS NEW?
Many of the concepts used in ASP.NET Core are not new to the open source community but might be new to some .NET developers. Some of the “new-to-you” features for ASP.NET Core include the ability to use widely accepted third party frameworks for both server-side and client-side needs. Developers may import server-side third party frameworks via npm and client-side third party frameworks via Bower.
Another new feature added in ASP.NET Core is the Startup.cs file. The Startup class is the entry point to an application and is required for all ASP.NET Core applications. The Startup class must define a Configure method. The Configure method specifies how your application will respond to individual HTTP requests. You can also setup error pages, static files, ASP.NET MVC, and Identity for your application. Startup also has an optional ConfigureServices method allowing you to configure services in your application, such as a database context, seed data, or a repository class.
ConfigureServices is called before the primary Configure method. This is notable because some of the features in the Configure method may require services that need to be added in the ConfigureServices method first. If you have been following the code linked above, you may have noticed that the services in the Services container are added using dependency. Microsoft decided to add dependency injection to ASP.NET Core applications by default. This removes the need to add a third party Inversion of Control (IoC) container!
In order to support a cross-platform model, ASP.NET Core is decoupled from the server environment that hosts the application. To accomplish this goal, Microsoft has implemented Kestrel web server, which serves as internal HTTP server receiving proxied requests from the overlying server.
To ensure that Kestrel is not exposed to the internet when deploying your ASP.NET Core application the use of some kind of reverse proxy server is necessary. If you are on a Windows platform, IIS is sufficient. If you happen to be deploying to a Mac or Linux based system, you will need to choose another option. Popular choices include Apache or Nginx. We followed the guide found here for setting up Nginx for deployment.
Nginx is an HTTP and reverse proxy server that is widely used in the open source community because it is fast, very resource efficient, and easy to scale. There are several scenarios in which you might want to use Apache instead of Nginx; however, that discussion is outside the scope of this post.
In this post, we introduced ASP.NET Core and discussed some of the changes and major differences pertinent to developers just starting out with this new product. We briefly covered the new ways you can pull in server-side and client-side dependencies. We also dove into the new Startup class and the role it plays in ASP.NET Core applications. Finally, we glossed over the deployment of Core applications as well as some basic considerations to take into account.
Sources and further reading:
- https://app.pluralsight.com/library/courses/aspdotnetcore-efcore-bootstrap-angular-web-app/table-of-contents (requires subscription)