-
Notifications
You must be signed in to change notification settings - Fork 58
[AspNetCoreModule] consider an 'auto-start' option #161
Comments
Shouldn't the application lifetime be controlled at the IIS app pool level as it is now? |
@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. |
@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. |
@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
👍 |
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. |
This issue was moved to aspnet/AspNetCoreModule#29 |
With a 'traditional' ASP.NET application, IIS could be configured to have the app pool "Always Running", which would trigger
Application_Start
or aStartup
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?
The text was updated successfully, but these errors were encountered: