In ASP.Net Core, the Startup class – referred to as Startup.cs in programming terms – is where all the action begins. In other words, the Startup class is executed first when the application starts.

Startup.cs file in .NET Core

The primary task of the Startup class is configuring the request pipeline, the series of request delegates that get called serially. This way, the class not only serves to be the starting point of the application but also determines the course the application would eventually take.

No wonder all of this makes the class a binding requirement in any ASP.Net Core application. Further, the class starts its operation from OWIN (Open Web Interface for .Net), which happens to be an open-source project and serves as a standard for an interface between Web Servers and .Net Web apps.

Here is a code snippet that shows how the Startup class is used in a program.

    public class Program
        public static void Main(string[] args)
            var host = new WebHostBuilder()

What the above program code does is it configures the webserver (in this case, Kestrel), sets the content directory, sets up IIS Integration, defines the Startup class for subsequent use. With core application being a Console app, you have to configure a web host to begin listening. It is the Program class that does the configuration.

Also, the Startup class as demoed above can have any access modifier (public, private, internal). As can be seen in the example above, the access modifier is set as public. It also isn’t mandatory to name the class as Startup. Rather, it can have any name as the programmer finds convenient.

For instance, .UseStartup<XYZStartup>() is also perfectly OK.

The Startup class though will depend on the particular application being coded and will vary accordingly. Here is how it looks like in most cases:

    public class Startup
        public void Configure(IApplicationBuilder app)

        public void ConfigureServices(IServiceCollection services)


Configure Function

The method enables the programmer to define the application request pipeline; or in other words, how the application is going to respond post an HTTP request. This is accomplished using the IApplicationBuilder instance that is part of the integrated IoC(Inversion of Control) container.

However, while the method shown above accepts IApplicationBuilder as a parameter, the method can also accept other parameters like IHostingEnvironment and ILoggerFactory. The use of these services is again purely optional. In any case, IApplicationBuilder, IHostingEnvironment, and ILoggerFactory are considered framework services injected by the integrated IoC container.

ConfigureServices Function

The primary purpose of this function (and from which it gets its name) is to configure services used by the application. The ConfigureServices function gets called the first time an application is requested. Another unique aspect with the ConfigureServices function is that it should always have the public access modifier. This is so to enable the environment to read the content from metadata.

The ConfigureServices function is also the place where the dependent classes can be registered with the built-in IoC container. Once the dependent classes get registered, those can be used anywhere within the application simply by mentioning the name as a parameter of the constructor of the class where its use is required. The rest is with the IoC container that injects the same automatically.

In fact, the ConfigureServices function happens to be a core feature of the ASP.NET Core architecture itself. It comes with the built-in IoC container to serve dependent objects using constructors. ASP.Net Core considers dependent class itself as a Service. In that way, the Service can be considered as a class that can be used in another class.

Also, any service that gets added to the ConfigureServices function becomes available for use in this method as well. Further, the IServiceCollection parameter forms part of the ConfigureServices function and is used to register services to the IoC container.


To sum things up, the Startup class lives up to its naming by serving as the entry point of the application. That also is the reason the class is irreplaceable so that it is a must for all applications to have the Startup class.

Related Articles

Last modified: September 13, 2019


Write a Reply or Comment

Your email address will not be published.