3

In old ASP.NET I could tell why my app stopped by looking at HostingEnvironment.ShutdownReason.

In ASP.NET Core, this doesn't exist. Where can I get this info?

grokky
  • 8,537
  • 20
  • 62
  • 96
  • In what context are you running this? Are you trying to start another process in c#? Know that all the AppDomain features in dotnet core were removed (on purpose) – Joel Harkes Jan 16 '17 at 16:48
  • Don't understand what you mean? I need that info so I can log why my app went offline. – grokky Jan 16 '17 at 16:50
  • Looking at the codes it could return, it is probably removed. Since in dotnet core you no longer use iis (directly) . But run standalone – Joel Harkes Jan 16 '17 at 16:50
  • Ehm, you app either runs or it doesn't. If it crashes its either because of unhandled exception or some very unusual error. There is no wrapper around your app that catches this. Your app just crashes/dies. – Joel Harkes Jan 16 '17 at 16:53
  • 1
    @JoelHarkes In pre-Core ASP.NET I could tell why the app died (app pool recycle, shared host config, unhandled error, by user request, etc.), by looking at this property. Are you saying Core is less functional? – grokky Jan 16 '17 at 16:55
  • Yes core is a subset and no, core just removed a lot of crap. For these functions to work. Iis would need to be highly integrated in your dotnet app, (adding a lot of crap and sluggishness). Now of you want this you should add it yourself for example with exit codes or a wrapper. It also simply makes it crash less. (There is no automatic appPool recycle, there is just one app running, no iis app pools) – Joel Harkes Jan 16 '17 at 16:59
  • @JoelHarkes In shared hosting [there is still an app pool, and IIS](http://learn.microsoft.com/en-us/aspnet/core/hosting/apppool). And they configure it to recycle. Site can go down because of memory pressure, etc. I need to know why, so I can fix the problem. – grokky Jan 16 '17 at 17:02
  • 1
    http://shazwazza.com/post/aspnet-core-application-shutdown-events/ – David Pine Jan 16 '17 at 17:16
  • @DavidPine Yeah I hook into those events to do my logging. But I'd like to also document the shutdown reason, if it's available. – grokky Jan 16 '17 at 17:19
  • 2
    @grokky that has not yet been implemented in **ASP.NET Core** and I'm not sure that it will ever be. Things are different now with kestrel, https://github.com/aspnet/KestrelHttpServer/search?utf8=%E2%9C%93&q=shutdown – David Pine Jan 16 '17 at 17:22

1 Answers1

0

There is no shutdown reason in ASP.NET Core. The good news is, the application dies for a lot less reasons now than it did before because of the new hosting model.

To put things in perspective, of the events listed on https://learn.microsoft.com/en-us/dotnet/api/system.web.applicationshutdownreason?view=netframework-4.8.1, the ones that are applicable in ASP.NET Core are:

  • None
  • ConfigurationChange (web.config change)

If we added this, maybe new custom one:

  • AppOffline detected
davidfowl
  • 37,120
  • 7
  • 93
  • 103
  • 3
    Thanks for the definitive answer. Problem is in shared hosting, devs depend on that info to determine why our apps crashed, or were manually/automatically taken offline by the hoster. I get the new hosting model is different, but that will make life really complicated for many of us. Most hosters are not forthcoming with providing logs or any advice, so we needed that info to know if our app needs more memory, more space, more processing power, whether the app pool is overloaded, crashed during startup, etc., etc. We can't know any of that now. *MANY* of us use shared hosting. – grokky Jan 17 '17 at 11:36
  • 2
    ...Arguably (?), *most*, not many, of us use shared hosting. Most web sites/apps are small/medium and run in shared hosting environments. In the future, it would be really great if you guys can look into this issue. Most of us will never run in Azure, so we need a feedback loop from the hoster to our apps. – grokky Jan 17 '17 at 11:39
  • Doesn't change the fact that the application dies for less reasons. Arguably, the only reason that isn't a crash would be if there was an app pool reset. If you can give me a specific scenario where the reason would help, I can tell you if that even applies to ASP.NET core applications. – davidfowl Jan 17 '17 at 13:37
  • 2
    `specific scenario` - https://stackoverflow.com/questions/69780442/how-do-you-cache-expensive-sql-calls-in-asp-net-core-5#comment123348046_69780442? – GSerg Oct 31 '21 at 18:55
  • Here are some of the `HostingEnvironment.ShutdownReason`s that would still apply to .NET 6 if we had a way to access them 1) Change in web.config, 2) Hosting environment shut down the application, 3) idle time limit was reached, 4) a change made to the physical path to the application. Also maybe this one, not sure: Max Recompilations Reached. For the above reasons that are still relevant to .NET 6 it sure would be nice to have a way to get the reason the hosting environment shutdown. – RonC Dec 13 '21 at 20:54
  • I agree it would be nice to have a string reason field for some of these. ASP.NET Core is host agnostic, and those reasons and all IIS specific. We can probably expose some IIS specific interface that has more of this information. – davidfowl Dec 18 '21 at 10:53
  • totally agree grokky. For the decades I have been a windows developer, MSVC developers never seem to have any experience with the issues of real world large scale commercial corporate bespoke applications, and how they cant all just be rewritten when they break them and repeatedly change something that worked and replace it with some massively over engineered design, or not at all, as in your case (and mine). – Mark Worrall Oct 24 '22 at 10:30
  • I updated the answer to be a bit more specific about what I meant about these events are very much less of an issue now. – davidfowl Jun 13 '23 at 16:41