Why not just set the app pool idle timeout as opposed to modifying the global app config and the rest of those things mentioned in the above link?
Regardless, if you put the hangfire server into a windows service, then there is need for neither. However, my question still stands - why the changes mentioned vs simply modifying the idle timeout value to 0
I’m by no means an IIS configuration expert, but using a windows service instead as your only background servers would prevent you from having to do that. If you have hangfire server running inside of your webapp (as many people do), you need to ensure the application is always running regardless of requests because the hangfire server doesn’t run as a request and therefore IIS doesn’t know about it. It runs on separate threads so making sure the app is always running in this case is crucial to prevent application shutdown in the middle of an executing job or to allow scheduled/recurring jobs to kick off.
Always running at the app pool level should still be isolated to your application unless you are sharing app pools for some reason which really should only happen under very specific use cases.
Even setting the idle timeout the application pool could potentially spin down. Always running ensures that neither IIS nor the server causes the pool to sleep.
As for IIS versus windows service, it’s really about preference and need. IIS allows hangfire to run within a web application (which allows the dashboard to be exposed through the browser) while the windows service isolates the service to a particular server.