Consider adding services.AddHttpContextAccessor() to AddAspNetCore()

[ossendorf-at-hoelscher]

Is your feature request related to a problem? Please describe.
I'm in the process of setting up a proof of concept solution where I need a minimum asp.net core application just to have an actual endpoint over the wire. But adding Csla to the services is not "just" calling AddCsla(o => o.AddAspNetCore()) but to also call AddHttpContextAccessor().

Describe the solution you'd like
AddAspNetCore() should internally call AddHttpContextAccessor() because it's required in that scenario anyways.
This would reduce the barrier on setting up a server. I had to check the samples to see how to correctly setup a server.

[rockfordlhotka]

I thought about that too, but was concerned that this might be an anti-pattern - for a library to start bringing in services from other sources in ways that aren't under control of the developer.

For example, some of our unit tests provide a mock accessor because the real one isn't available or valid.

[StefanOssendorf]

I don't think that's an anti pattern. If we start using the options system we have to include that system in our di to get it even working. And adding something is not a problem. Last registration wins and is the default for di. So there are no problems as long as a user registers it's own implementation afterwards. And that is currently common in the ecosystem.

[rockfordlhotka]

My only other thought is that it could get registered twice, which wouldn't cause a functional difference. I suppose that's not a blocker.

[StefanOssendorf]

It's not added twice. Most of all framework dependencies are added with Try.
https://github.com/dotnet/aspnetcore/blob/ec389c71560ceba39148831343ba8f20962e0228/src/Http/Http/src/HttpServiceCollectionExtensions.cs#L23