[AspNetCoreModule] consider an 'auto-start' option

[Tratcher]

From @tuespetre on May 2, 2016 21:1

With a 'traditional' ASP.NET application, IIS could be configured to have the app pool "Always Running", which would trigger Application_Start or a Startup class, giving developers a chance to schedule recurring background tasks and trust that they ran as long as IIS and the app pool were running. This was great for simple, small-scale deployment scenarios.

HttpPlatformHandler was not as friendly and enabling for such scenarios. Now that HttpPlatformHandler has been forked to AspNetCoreModule, could an option be added that causes the module to start the application immediately instead of waiting for a request?

Copied from original issue: aspnet/IISIntegration#161

[Tratcher]

From @mikes-gh on May 12, 2016 8:2

Shouldn't the application lifetime be controlled at the IIS app pool level as it is now?

[Tratcher]

From @guardrex on May 12, 2016 15:54

@mikes-gh It is, @tuespetre is calling attention to the startup nature of the app. Take a Windows Service, for example. When you start that service and set it to automatically start, you know that your service is going to fire right up and always run when the server restarts. We don't have that for IIS apps, and I think this is a great idea.

[Tratcher]

From @mikes-gh on May 12, 2016 16:38

@guardrex Being devils advocate 😄 I'm not sure web.config could control the app pool process lifetime variables such as "Always Running" ? The app pool might have more than one app in which case you might have 2 settings fighting each other. Unless we change the model to one app pol per app.
If @tuespetre is saying lets replace Application Initialization with a new mechanism in AspnetcoreModule I whole heartily agree. Its a real pain at the mo and pretty much every app I write I want always running and warmed up by default.

[Tratcher]

From @guardrex on May 12, 2016 16:58

@mikes-gh AFAIK that's a non-starter b/c they issued earlier guidance: one app for one AppPool ... but that may have changed. I don't recall a more recent discussion on it.

I wasn't really too concerned about web.config setting it up; although, I believe you can set Idle Time-out with the <processModel> and the Always Running with applicationInitialization in web.config, but I've never done it. If I could just set things up manually, I'd be happy.

I want always running and warmed up by default.

👍

[Tratcher]

We plan to use this feature to replace the DEBUG request (#102) VS currently sends to start the process. When that happens remove the DEBUG filter from IISMiddleware.

[sergioadh]

Is there any updates on this feature? All the applications we have developed need to be ready when they are called, without waming up it first calls are painfully slow. And since the application lifetime is not really managed by IIS (only the application pool lifetime which doesn't impact the app at all) then we have no control of when the application goes down and up again.

[ghord]

Note that background job runners such as Hangfire have no way to properly work on IIS under .Net Core because of missing IProcessHostPreloadClient support.

[snowyowlapps]

Anyone have an update on this?

[tuespetre]

Funny you post just now, I cloned a bit ago to have a crack at it 💥

[tuespetre]

Eh, so it turns out setting AlwaysRunning and enabling preload works out well enough for us. I'm not going to do anything else with this.

[neumartin]

@tuespetre can you tell me how to enable preload?
Thanks!