I'm having the same issue described in this question where I am losing HttpContext.Current after an async operation. The main difference between that question and mine, is that I've applied all of the possible solutions to resolve it - which all work on my PC but don't work when we deploy to the webserver, which has .NET 4.8 installed. Another thing to note is that when we apply the settings - we can see that the SynchronizationContext is of type AspNetSynchronizationContext (and not Legacy, so we seem to have what we want).
We checked IIS App Settings and made sure there were no manually added or negating settings (like <add key="aspnet:UseTaskFriendlySynchronizationContext" value="false" /> or something similar) and there weren't. We also tried <httpRuntime targetFramework="4.5" /> - which did not work.
Are there any other settings/configurations/possible .NET CLR explanations that would make this setting: <add key="aspnet:UseTaskFriendlySynchronizationContext" value="true" /> not pass the HttpContext.Current to a thread while performing async operations?
Also - if I have <httpRuntime targetFramework="4.5" /> - and I see a LegacyAspNetSynchronizationContext - what could be the root cause?
Example (locally) that works, but breaks on the webserver:
[HttpGet]
[Route("api/DelayTest")]
public async Task<int> Test()
{
var ctx = System.Web.HttpContext.Current; // not null
await Task.Delay(new TimeSpan(0, 0, 5));
ctx = HttpContext.Current; //null here (which causes issues)
return 0;
}
Note: We are targeting .NET 4.5:
<compilation debug="true" targetFramework="4.5" />
<httpRuntime targetFramework="4.5" maxQueryStringLength="6000" />
