[Announcement] The IHttpContextAccessor service is not registered by default

[Tratcher]

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

[aminebizid]

So of we don't inject httpcontext we won't have Access to User in our controllers ?

[Tratcher]

@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.

[tugberkugurlu]

In that sample, you are registering it as a singleton. Shouldn't it be a scoped instance?

[mikes-gh]

services.AddIdentity registers this anyway.

https://github.com/aspnet/Identity/blob/79dbed5a924e96a22b23ae6c84731e0ac806c2b5/src/Microsoft.AspNetCore.Identity/IdentityServiceCollectionExtensions.cs#L54

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.
So if using identity you get IHttpContextAccessor 'magically'.
Even though HttpConext is available in controller I still want to avoid new on my objects and prefer DI.

Now it is not clear when you need to register IHttpContextAccessor.
What would be the result of registering it twice.

ie

services.AddIdentity<ApplicationUser, IdentityRole>()
                .AddEntityFrameworkStores<ApplicationDbContext>()
                .AddDefaultTokenProviders();
            services.Configure<IdentityOptions>(options =>
            {
                options.Cookies.ApplicationCookie.LoginPath = new PathString("/default/Account/Login/");
            });

            services.AddMvc();
            services.AddAuthorization();
            services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();

The above code runs fine but is there a performance hit to AddIdentity reqistering IHttpContextAccessor and registering it myself.
I would prefer to register it explicitly as it is clearer to my code.

[davidfowl]

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?

In that sample, you are registering it as a singleton. Shouldn't it be a scoped instance?

It's fine being a singleton because the backing store is async local.

[mikes-gh]

@davidfowl

Performance hit? Is that speculation or did you measure?

Speculation/Question

I am just not sure of the mechanics of registering it again.

AddIdentity is already providing an instance of HttpContextAccessor but I prefer to explicitly register it.
I don't perceive any performance hit (I didn't notice when IHttpContextAccessor instatiation was removed from Hosting Either :-).

I just wanted to make sure there wasn't a problem registering it again.

[davidfowl]

There is no problem registering it again and certainly no measurable performance hit.

[mikes-gh]

@Tratcher [edit] sorry Elion wrong person re the advice to use

services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();

Would it not be better to advise using the TryAdd version

services.TryAddSingleton<IHttpContextAccessor, HttpContextAccessor>();

since it may not be clear that IHttpContextAccessor may already be registered by another service and we don't need 2 instances.

That way if IHttpContextAccessor is already registered by another service eg AddIdentity a duplicate is not created. Other aspnet services use the TryAdd version for this reason I believe.
See my discussion above with @davidfowl

[brockallen]

In that sample, you are registering it as a singleton. Shouldn't it be a scoped instance?

It's fine being a singleton because the backing store is async local.

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.

[Tratcher]

@mikes-gh Sure, TryAdd is slightly better, but shouldn't affect functionality or perf.