Why do we have a Main() method (entry method) in the ASP.NET Core Web Application ? What's the reason behind this approach?

Viewed 631

Program class contains a public static void Main() method. As we already know, when we create a console application in .net then by default the .NET Framework creates a class (i.e. Program class) with the Main Method. We also know that the Main() method is the entry point for that console application execution.

Now the question is, here we are not creating a console application, here we create an ASP.NET Core Web Application but application create like console app with Main method as entry point. It's does make sense now ,we can configure the application pipeline and http request pipeline. It's nice idea.

But

Is there any other specific reason behind this architectural approach?

2 Answers

Because it is platform-independent that way.

Let's put it this way: They could create a DLL with some specific entry-point, and assume it's always consumed by IIS via ISAPI. But what about the cases where you don't run it on IIS, not via ISAPI, and not on Windows ?

That's right, you'd have to program some modules for each and every webserver out there, in order for it to be able to interact with your DLL. Plus you'd need a web-server. You might also need to update all of those modules whenever something changes. And then you need to package it for a boatload of different Linux distros, plus Mac and Windows, and Android and iPhone, etc.

And why would you do that ?
For that it only runs on IIS and only on Windows ?
Bad idea.
Nowadays, most servers run Linux, so do most routers and printers, while most mobiles run Android (aka Linux) or iOS, and most TV OSes are Linux-based.

If you have a main method, you can create a simple console program, with which can start a web-server on a certain port, which you can then use to forward traffic to (from NGINX/Apache via remote-proxy). Or you can forward SSL traffic directely to that web-server via HAproxy.

No IIS or ISAPI required.
If you use HAproxy, no NGINX or Apache required, too - because you can forward directely to kestrel.
And if it must, it can run inside IIS as well.
Maybe that makes IIS integration a little bit more complicated, but it also makes integrating into a Linux/Unix/Mac-environment (or any other, such as mobile phones) so much easier. And as said, most servers use Linux nowadays. Especially if run in containers like Docker/LXC.

It would be absolutely breathtakingly monumentally stupid to do anything else but that.
Also, it's a silent admission that they (MS) lost in the server space, and are now salvaging what there is to salvage (however, that last sentence is just my opinon, not necessarely a fact).

Why is it required.

  • Point 1: We don't have Global.asax that derives from HttpApplication, the entry point, and the main component that configures everything require to set up the ASP.NET pipeline, even if you have no Global.asax, as soon as a request comes to IIS HttpApplication object is created by the framework that holds HttpRequest, HttpResponse object, in .NET Framework.
    Similarly in .NET Core, to configure the Request Processing pipeline, anyhow you need to call Startup and provide him all the necessary configurations, which is done by the Main() while creating the Host.

  • Point 2: ASP.NET Core is cross-platform, and Kestrel is the built-in server that is going to host the app on all platforms except on windows where you can host in-process, so you need to configure Kestrel and tell him to host the App, this is done by the UseKestrel() extension method, at the same time IIS, can also be used as a reverse proxy, obviously, on windows, you will never use reverse proxy as you have the option to host in-process, but if you wish then you can configure using UseIISIntegration() extension method, now you might be thinking, where all these methods are, these are defaults and host.CreateDeafultBuilder() does all these for you. Configuring Logging, DI, Services, reading Configuration from sources like appsettings.json or appsettings.{environment}.json etc are all done while creating the host.

Now I think, you got the Idea behind Main().

Related