David Fowler

@halter73 Can you clarify? This API should not exist on anything that isn't IIS specific and it would couple the code in a way that was undesirable. This is why...

I think it's a bad idea to expose it as a static API. We don't do *anything* else like this in ASP.NET Core (it's one of the original design principles)....

Let me try to propose some alternatives. We could have an IISWebHostEnvironment that exposes all of the static state understood by IIS as first class properties: ```C# class IISWebHostEnvironment :...

Another approach would be a feature based one: ```C# interface IISEnvironmentFeature { string ConfigurationPath { get; } } ``` We add an IFeatureCollection to IWebHostEnvironment: ```diff interface IWebHostEnvironment { +...

Nope, it's not early enough. That's the problem.

@CZEMacLeod I think it makes sense to expose a bunch of properties as well.

I’m sure there are more things that don’t get cleared when assemblies get unloaded. This isn’t something we’ve designed for so I would expect this to be the tip of...

cc @janvorli

We’re discussion having an optional middleware that can sniff plaintext http2 traffic for this so we can gauge interest. It has come up multiple times so maybe worth looking at...

Yes, it would be opt in.