Why Host a Publicly-Facing Web App as a Windows Service?

Question

I have read documentation, articles, blogs, etc. on hosting web applications as a Windows Service. They only address two aspects:

• That it is possible, how to set up, and execute
• Because IIS may not be a viable option

I'm not satisfied with "because you can", and "there is no IIS", and even "because the app would automatically start when we reboot the server".

It seems to me that a web app hosted as a Windows Service lives only on a particular user's machine because only that person would use it. Maybe it makes sense to host/run top-level administrative apps as Windows Services, that only a system administrator can access.

But for web applications that have logins and normal users, and are intended to be made publicly available, why would we still want to serve those as a Windows Service? Why could we not get IIS set up for this purpose?

Perhaps there are Infrastructure-level concepts and principles that I don't know as a web developer, and I would appreciate any Infrastructure perspective on why we might want to host a public-facing web application as a Windows Service.

Answer 1

I'm not satisfied with "because you can"

I'm afraid it's the answer though. There are in fact many subtleties and layers to your question and its answers, like ogres and onions.

Key concepts

• HTTP: the web protocol.
• HTTP.sys: Windows' implementation of a kernel-mode HTTP listener.
• Kestrel/Cassini/HttpListener: examples of user-mode HTTP listeners.
• IIS: a group of related software and APIs that allow configuring things called "web applications" or "web sites", with modules and handlers, configurations (authentication, authorization, content types, RAMMFAR and whatnot) and application pools, a nice management console UI and APIs, activation services and much, much more. Uses HTTP.sys for the heavy lifting of the requests and responses.
• ASP.NET: an application framework that ties HTTP requests and responses to .NET objects.
• ASP.NET Core: the open-source revamp of ASP.NET.

Tying servers to frameworks

Now to clear the air: one does definitely not need IIS to run an ASP.NET (Core or non-Core) web application. One just needs any web server knowing how to run managed code and invoking the proper APIs so user code gets called at the right entry point, with the appropriate properties of the HttpContext and the HttpRequest and HttpResponse objects assigned.

That's about all you need to get an ASP.NET app up and running. See mod_mono: an Apache module that can run ASP.NET applications. See also FastCGI. On .NET Framework and starting from IIS 7, it's the ASP.NET Module that ties IIS to ASP.NET. Before that, it was an ISAPI filter installed by the Framework installer. On .NET (Core) with ASP.NET Core, it's the ASP.NET Core Module (ANCM).

Built-in

ASP.NET Core applications have had an ever-improving built-in webserver called Kestrel. Kestrel is a fully-fledged user-mode production-ready HTTP server. It gets started when you create a new web app in .NET and execute your project. It gets compiled in when you compile it. It's run when the app is run.

Reverse Proxy

It does not run when you run your ASP.NET Core app within IIS in InProcess hosting mode (the default since forever). Instead, ANCM will fiddle with the proper properties and have your request end up in user code, without reverse proxying requests.

Reverse proxying happens when you run out of process. Then your app will start Kestrel as a web server, listen on port 5000 for example, and tell IIS that it has to forward requests to that port.

When to use IIS

Now if you have a user-facing non-core web application (WebForms, MVC, Razor Pages) and a licensed Windows server to spare, I'd say: by all means, use IIS. It's the de facto hosting platform for that scenario, so why wouldn't you.

If you need port sharing (like 80 & 443) because multiple web apps on the same server need those ports, you need HTTP.sys - or a user-mode alternative supporting port sharing, which Kestrel doesn't. And if you want to use the additional benefits of other modules, of configuration, of APIs and consoles to manage your web applications visually or programmatically - use IIS!

When not to use IIS

Now if you have a web app that doesn't need all of IIS's nor any of HTTP.sys's config and features, because it's running on its Rémi or because your server doesn't nor can have IIS installed, then by all means go with Kestrel.

It's totally a supported hosting scenario to have the Kestrel server that's built in to the (assemblies orbiting your) app face the public.

And then, to have this app restarted on reboot, to have its uptime monitored, to have it restarted on failure: host it in a Windows Service!

The same goes for non-public-facing web applications. If you want to self-host a bunch of ASP.NET Core API controllers that only other apps talk to, which don't even need port 443 but can run on other ports: host Kestrel from within your app, Windows Service or not!

You could even go lower-level and use HttpListener yourself. One does not need to use ASP.NET, it's just a framework that makes life easier by abstracting away common things when dealing with HTTP.

Related reading

• how to self host an existing asp.net webform
• IIS vs HTTP.SYS for hosting an internet ASP.NET core website
• MS Learn: Introduction to IIS Architectures
• MS Learn: Web server implementations in ASP.NET Core (and its subpages about Kestrel and HTTP.sys)

Answer 2

OK, let's try this again, and break this down into bite sized parts and issues.

That it is possible, how to set up, and execute

It actually in most cases not a issue of "possible". It is a question of required.

To run a asp.net web site (.net framework) you REQUIRE to setup IIS when using .net framework, and if you using .net core, then a whole web server can be (optionally) included in your final product.

In other words, to setup a web server and use, or not use IIS, you don't have a choice here. You MUST have a working and compatible web server to run your asp.net web site.

If you build some software for Windows, then that software will not run on an Android phone. The same applies to your software (web site) you build with .net tools.

The application and web site you build will not work, and can't be run unless you ALSO provide a web server. And that web server has to be running BEFORE you try and run your asp.net web site.

So, really, the issue of running a web server as a "service" as opposed to say having the web site start up when the web site is being used? Not all that of a big deal.

However, the MOST important concept here is that such software (the web site you built) will not run without a web server.

So, you can kind of think of this issue like when you use a database like SQL Server. You could on your computer startup, have SQL Server startup and run as a service.

Or, I suppose you could have when your software wants to use such a database, it could start a copy of SQL server. But, at the end of the day, note how EITHER WAY, you STILL need that database server running for the database to work.

The same concept applies to a web server.

So, with the above concept clear, we can now address the 2nd issue:

Because IIS may not be a viable option

Well, if your software requires IIS, then you do NOT have a choice here. If you build your site with asp.net + .net framework, then you MUST install + setup IIS for that software to work. So, if IIS is not a choice that you can make, or is not viable as you note?

Then you can't run that site, and you can't use asp.net + .net framework for that choice. In other words if IIS is not a choice, or will not be available? Then you can't run that site, and you have to use different development tools.

Remember, even during development, when you hit f5 to run/debug your code? (.net framework)

Visual Studio will start up a copy of IIS (IIS express version). Without that web server running, then your software will not work. So, after hitting F5, Visual Studio starts a copy of IIS, waits for it to complete startup and is now running, and then Visual Studio passes your web pages and site to that running copy of IIS.

And even if you purchase some low cost web hosting, then that web hosting will have a running copy of IIS for your software to use. And without that running copy of IIS, then your software will not run.

In the case of .net core? (not .net framework). Then the choices are less restrictive, since you now don't need IIS. However, you STILL in ALL cases need a compatible web server that can run your .net core code.

So, then how does a .net core site run say on a Linux site, and that server has say Apache web server? (which cannot run the .net core web site)?

Well, during a publish, there is a option in Visual Studio, and it will INCLUDE in your publish a whole separate web server!

Note now once again, a WHOLE web site server is included in your publish.

And note once again, this is required, and your asp.net + .net core site will not run, will not work, and ONLY works WHEN you include that WHOLE web server along with your deployment.

For above, then the existing web server (Say Apache) does not really run your web site, but only acts as a proxy, or simple "router" to hand the pages off to that working and running and valid .net core web server!

So at the end of the day:

You will need IIS running and working BEFORE your web site written in asp.net + .net framework runs. And if you require .net framework, then you have to use IIS, and that web server ONLY runs on a windows box right now.

If you build to .net core, then you can at publish time include a WHOLE .net core compatible web server, and once again, that web server has to be up and running BEFORE your software can be run.

So, even if we throw out the issue of a service vs a running program. Either way, and in all cases, you still require a valid running copy of that web server, and without that valid running copy of that web server. Your software can't run, and will not work.

And since it does not make sense to start, and then stop the web server over and over as your software runs; then in most cases, it is better to have the web site up and running at all times, and thus such web servers are usually run as a service.

The web site you build still can't run, and you can't JUST launch your software unless that web site is up and running.

Your software in all cases still requires a valid working and running web server to process those web pages.

So, just keep in mind, that no matter how you approach this issue, your software built in Visual Studio as a web site requires a valid and working and running copy of a web server to work, and that web site cannot be just any web server, but ONLY ones that are designed to work with the .net core, or .net framework.

The web server is for the most part a separate "thing" that is required to be up and running, and ready to process any web pages requested, including the ones you built with Visual studio.

Those web pages don't work if you just try to load or launch the web page in some file folder. Such pages have to be first processed by the web server before being sent to the client side browser. And that processing of those web pages requires a compatible .net web server for such pages to work correctly when .net core or .net framework code is involved for such pages.

So, just keep in mind, you can't JUST run your web application as stand alone, such a web site will only work and and only run when paired with a web server, and a .net compatible web server.