Understanding The Role of Startup.cs File In ASP.NET Core Project

Sunny Sharma
8y
58.8k
0
6

Article

This post is a continuation of my previous articles on ASP.NET Core. Please read them here:

Before I start with Startup class, I would like to give you an idea about DNX, or may be just refresh it if you already know!

What is DNX? How does it work?

The .NET Execution Environment (DNX) is a software development kit (SDK) and runtime environment that has everything you need to build and run .NET applications for Windows, Mac and Linux. It provides a host process, CLR hosting logic and managed entry point discovery. DNX was built for running cross-platform ASP.NET Web applications, but it can run other types of .NET applications, too, such as cross-platform console apps. It works right from your command line tool.

(source: docs.asp.net)

Here's a brief expo of where we are:

Okay, let's understand the basic of the Startup class:

What is Startup.cs file? What role dos it play in ASP.NET Core project?

The Startup class is an enhanced way to boot up your app, and dependency injection is now an integral part of ASP.NET. The global.asax file is not available ASP.NET 5. In earlier versions of ASP.NET, the System.Web assembly took care of starting the app, and the global.asax file had methods (Application_Start / Application_End etc.) that were called by System.Web in which you could provide custom logic. The steps needed to start up an application are now determined by you using the Startup class. The Startup class contains a Main method. That's the entry point for the application.

When the DNX executes the application, it looks for this method and calls it just like earlier versions of .NET. Almost all .NET applications boot using the Main method. The implementation of the Main method here tells the Web Application to run using the Startup class. That's, in fact, the class the Main method is in. And it passes in any command line arguments. The Startup class is just a simple class not deriving from another class or implementing an interface. The DNX hosting environment will by convention call two methods: ConfigureServices and Configure.

The DNX executes Main, and by convention calls ConfigureServices and Configure methods . The purpose of the ConfigureServices method is to configure dependency injection. Dependency injection in previous versions of .NET was optional. In ASP.NET 5, it is integrated. The dependency injection mechanism depends on an IoC (Inversion of Control) container. Typically when an application starts up, types, like a class, are registered in the container. In dependency injection terms, these types are called services. Once registered, other types can ask the container for an instance of that type. Also, during registration, you can determine what the lifetime should be of that instance.

The lifetime of an object is managed by the container. A transient lifetime means a new instance of the type is created every time it is asked for. A scoped lifetime means the instance will live until the web request is completely handled. And a singleton lifetime means once an instance is created, the same instance will be supplied every time until the app closes.

Although you can still easily plug in your own dependency injection framework like Ninject or Autofac or Unity, ASP.NET 5 comes with a default dependency injector out of the box. The container is invisibly created at application startup and filled with ASP.NET 5's services. At application startup, the hosting layer of ASP.NET gives you an opportunity to register your own types in the container by calling the ConfigureServices method in the Startup class. By supplying an IServiceCollection object as a parameter of ConfigureServices method, you get the API to do the registering.

Let's create an interface, for example, say it IScoreService:

Now a class, say ScoreService, should implement the interface.

Here's how I register this class with the built-in dependency injection container:

Now, whenever an object of type IServiceCollection will be demanded, the same object (as it has singleton scope) will be handed over. We'll see how this injection works in next post.

Let's come to the next method in Startup class: Configure

You can see it accepts an interface object of another service called ApplicationBuilder. This object is injected by the dependency injector. The Configure method configures the HTTP request pipeline of ASP.NET. The pipeline specifies how the application should respond to HTTP requests. When your application receives a request from the browser, the request goes through the pipeline and back.

When there's nothing in the pipeline, nothing happens. So you need to plug in stuff you need in the pipeline. The individual parts that make up the pipeline are called middleware. For example, the MVC framework can be plugged in as middleware. But you might do some authentication first. In that case, configure a piece of middleware before MVC. Even the ability to serve static files containing JavaScript and CSS have to be configured as middleware. While travelling through the pipeline, data about the request travels through the pipeline and gets read and manipulated by the middleware and eventually the result is the response.

When the request is made, it first arrives at the web server. I will assume that you use IIS for now. IIS then invokes the DNX which will load the CLR and then looks for an entry point, the Main method, in your application and executes it. The main method configures the pipeline by using the Startup class, and the request is pushed through the pipeline, processed by the middlewares which will produce the response.

Using the pipeline you only plugin what you need. This is much more efficient than the old system, web approach, and it will surprise you how performant and resource friendly it is.

Thanks for reading. Hope this post helped you understand the role of Startup class in ASP.NET Core project.

Please share your thoughts and feedback using the comments section!