-
Notifications
You must be signed in to change notification settings - Fork 311
[Announcement] The IHttpContextAccessor service is not registered by default #793
Comments
So of we don't inject httpcontext we won't have Access to User in our controllers ? |
@Zigzag95 IHttpContextAccessor is only intended for accessing the HttpContext in locations where it's not directly available. HttpContext and User are directly available in MVC Controllers so you do not need IHttpContextAccessor. |
In that sample, you are registering it as a singleton. Shouldn't it be a scoped instance? |
A lot of applications will need identity so this change is confusing as if you use identity you get IHttpContextAccessor but if you don't it doesn't. Now it is not clear when you need to register IHttpContextAccessor. ie
The above code runs fine but is there a performance hit to AddIdentity reqistering IHttpContextAccessor and registering it myself. |
Performance hit? Is that speculation or did you measure?
It's fine being a singleton because the backing store is async local. |
Speculation/Question I am just not sure of the mechanics of registering it again.
I just wanted to make sure there wasn't a problem registering it again. |
There is no problem registering it again and certainly no measurable performance hit. |
@Tratcher [edit] sorry Elion wrong person re the advice to use
Would it not be better to advise using the TryAdd version
since it may not be clear that That way if IHttpContextAccessor is already registered by another service eg |
Actually if you register it as a Transient on .NET Core then it doesn't work properly since the implementation for .NET Core is using a AsyncLocal which relies upon the instance variable to track the TLS storage slot. So it has to be registered as a singleton on .NET Core. |
@mikes-gh Sure, TryAdd is slightly better, but shouldn't affect functionality or perf. |
@Tratcher I may not be understanding the mechanics but if there is no performance impact to registering a second instance why was the default instance removed? |
Only one registered instance gets used so there is a perf difference between 0 and 1, but not between 1 and 2. |
Ok got it thanks . I still think the announcement should sugest TryAdd though. |
It doesn't matter -- it must be a singleton, so doing additional DI config with different lifetimes won't work anyway. |
@brockallen |
This distinction wasn't my point. My point was that the class (either by design or by accident) will only work as a singleton. |
Conceptually the DI provider is a typed dictionary with the service type as the key. So any service can be registered in a for loop a thousand times, it won't have much effect apart from startup performance - which is negligible unless you actually do use a for loop. I believe the scoping of any service is fixed once it is registered for the first time, I believe that's true for the implementation type as well - correct me if I'm wrong. I recall @DamianEdwards fixed a bug with caching on stage at a conference (//Build?) by simply registering a singleton before registering EF - which would register the same service type as transient. I'm just too lazy to test it right now, it'll probably take about two minutes. But if the implementation type nor the scoping can't be changed for a service type after registering it for the first time, one could ask why there exists TryAdd overloads at all. |
Or maybe all service registering should be using TryAdd logic. |
This announcement creates a very awkward feeling. The way it's stated gives the impression that we should not use it. But, identity is using it, so a vast majority of apps developed with aspnetcore will depend on it, so I guess (hope) that the cost of this is not that bad or there may be something extremely wrong with identity implementation. |
@Tratcher The above is the justification for removal of IHttpContextAccessor by default. Should we be concerned about performance in all apps that use identity? |
@mikes-gh one of the major tenants of Asp.Net Core is pay-for-play, e.g. you only pay the costs of the components you use. Yes, many apps will use Identity and those apps will have higher costs than apps that don't (and not only because of IHttpContextAccessor). The added cost is not prohibitive, just it's unnecessary for other kinds of applications. |
Thanks for clarifying that :). |
The HttpContextAccessor seems to be registered by default in .NET Core 2.0.2. This is partially shown in my issue on StackOverflow. |
No, the stack does not register it by default, but one of your dependencies may. For example ApplicationInsights registers it. |
It is registered in debug mode but in publish mode it is not registered. What is the differences between them? |
@ahmetsevgili I have the same problem. Have you already solved it? Help me, please |
That may be ApplicationInsights only registering it when enabled. |
Application Insights is automatically registered in your application when you launch it under the debugger in Visual Studio, such that you can see & search events coming from your application while debugging in the VS Application Insights search experience. This is the most likely cause of the |
@promanchenko-softheme, use like @Tratcher said that above. Both debug and publish mode work fine after adding my ConfigureServices snippet like below
|
Visual Studio debugger registering |
Experienced this issue in a slightly different context to what's already been posted. When publishing an ASP.NET Core 2 API project via our CI process to an IIS server the following exception is raised:
Locally, we're debugging using Kestral and the exception doesn't raise. Adding |
That's going to be fixed in 2.1, it has to do with the fact that application insights was being injected in visual studio by default and adding those services but only when debugging. We're making some adjustments so we don't have a different debug/non-debug experience by default. |
So does that mean adding back HttpContextAccessor service by default? |
No |
How is it solved then? Code analyzer to catch the dependency in debug build? or..... |
As |
IHttpContextAccessor can be used to access the HttpContext for the current thread. However, maintaining this state has non-trivial performance costs so it has been removed from the default set of services. Developers that depend on it can add it back as needed:
services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
RE: aspnet/HttpAbstractions#473
The text was updated successfully, but these errors were encountered: