I'd like to add a SocketsHttpHandler to an HttpClient that I am creating via AddHttpClient in Startup.cs. The point of that is to be able to inject instrumentation etc. in the HttpClient via a factory.
This does not give me the option to use the constructor of HttpClient, which is where you'd usually add a SocketsHttpHandler.
Also, I don't see any obvious property etc. I can use to add it later.
...aaaand as is traditional I found the answer five minutes later. Never matters how long you look before, does it now?
How I can change configuration of HttpMessageHandler from Polly retry?
.ConfigurePrimaryHttpMessageHandler(() => new SocketsHttpHandler
{
MaxConnectionsPerServer = 3,
})
Related
If I use _httpClientFactory.CreateClient() in a singleton (no name for the client, I set it up when I use it)
Should I add/specify an empty services.AddHttpClient(); at startup or is that not necessary?
You should only specify empty services.AddHttpClient(); on startup. You could pass it name parameter if you want to configure "specific" HttpClient that you will later call by name (for example add base address or headers). Otherwise IHttpClientFactory will give you not configured one (like calling new HttpClient())
For example:
services.AddHttpClient("MyApiClient").ConfigureHttpClient(client =>
{
client.BaseAddress = new Uri(configuration["MyApiUrl"]);
});
and later calling factory like:
_httpClientFactory.CreateClient("MyApiClient");
will give you HttpClient with configured base address.
The services.AddHttpClient(); in your startup class is used to configure an IHttpClientFactory instance,
which is then used to create and manage named HttpClient instances.
If you are creating an instance of HttpClient directly with _httpClientFactory.CreateClient(), without specifying a named client,
what i suggest is you don't need to add the services.AddHttpClient(); line in the Startup class.
FACT:
This line is necessary only if you plan to use the IHttpClientFactory to create named HttpClient instances.
for More visit: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/http-requests?view=aspnetcore-7.0
I am new to ASP.Net Core and I am trying to implement ASP.NET Core DI.
I configured like below in ConfigureServices Method in Startup.cs
services.AddScoped<DbContext, AutomationDbContext>();
services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
services.AddTransient<IUserService, UserService>();
In UserService Constructor, I am trying to use DI. I think below is NOT the right way to implement this.
public UserService(IHttpContextAccessor httpContextAccessor, AutomationDbContext automationDbContext, IConfiguration configuration)
{
this.configuration = configuration;
this.optionsBuilder = new DbContextOptionsBuilder<AutomationDbContext>();
var connectionString = this.configuration.GetConnectionString("Automation");
this.optionsBuilder.UseSqlServer(connectionString);
this.automationDbContext = new AutomationDbContext(this.optionsBuilder.Options);
this.httpContext = httpContextAccessor.HttpContext;
}
I don't like building optionsbuilder in constructor and get connectionstring.
What would be the better place to build these optionsBuilder and pass in constructor.
You need to use services.AddDbContext<TContext> instead:
services.AddDbContext<AutomationDbContext>(o =>
o.UseSqlServer(Configuration.GetConnectionString("Automation")));
Then, just inject your context:
public UserService(IHttpContextAccessor httpContextAccessor, AutomationDbContext automationDbContext)
As for IHttpContextAccessor, you should simply use:
services.AddHttpContextAccessor();
However, I would encourage you to strongly consider whether you actually need this in your service or not. If you need something like the current user's id, that should be passed into the method that needs it, not retrieved from within your service.
UPDATE
Since it was brought up, let me elucidate the reasons why adding your context in the way you currently are is incorrect, since it will shed a little light on how DI works in general.
First, you're binding DbContext directly to AutomationDbContext, which means you can then only use that one context. Maybe you don't need more than one context... now. That could change later. Second, when you register a service in that way, you can only inject the abstract type, i.e. DbContext here. The service registration literally means "when you see DbContext, inject an instance of AutomationDbContext". If you try to inject AutomationDbContext directly, as you're currently doing in your controller, that will actually throw an exception because that type is not actually registered as service: DbContext is. Third, AddScoped provides no real ability to configure the context, which is of course the part your were missing. There's ways to work around this such as using the factory overload of AddScoped or defining OnConfiguring on your context, but both of those are substandard to just using the right method in the first place: AddDbContext<TContext>
For what it's worth, there's also somewhat of a fourth reason, in that you can opt to use AddDbContextPool<TContext> instead of AddDbContext<TContext>, for connection pooling. There's no other way to set that up, so if you did want/need connection pooling, you'll never get there with AddScoped.
I have an application (IJobInit) that uses a list from JSON settings to create multiple instances of a class (IJob). This class does some work using two other dependencies, IInputClient and IOutputClient. It uses M.Extensions.DependencyInjection to create a container which is handed off to AutoFac to create an IContainer.
IJobInit(IContainer container)
I would like IInputClient to be configured different for each instance of IJob. Speficially, I'd like to pass in a secret for it to use. The result would be:
IInputClient(HttpClient client)
where HttpClient is configured using ConfigureHttpClient such that IJob does not know that it is pre-authenticated. This would also be suitable:
IInputClient(ISecretProvider secretsProvider, string secretName)
The end result is three instances of IJob with IInputClient configured differently.
IJob(IInputClient inputClient1, IOutputClient outputClient)
IJob(IInputClient inputClient2, IOutputClient outputClient)
IJob(IInputClient inputClient3, IOutputClient outputClient)
How do I achieve this? I was looking at Autofac scopes but those controlwhen an instance is created without any control over its configuration (unless I missed it).
A colleague suggested that I could host each instance of IJob in its own process with its own configuration which is possible but I'm trying to host all the jobs in a single Azure Function and use the list in config to create the inner jobs.
Thanks!
I'm not totally happy with this solution but it works for now.
private async Task<IInputClient> GetClientAsync(string secretId)
{
HttpClient httpClient = this.httpClientFactory.CreateClient();
string secret = await this.secretsProvider.GetSecretAsync(secretId);
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", Convert.ToBase64String(Encoding.ASCII.GetBytes(string.Concat(":", secret))));
return this.scope.Resolve<IInputClient>(new TypedParameter(typeof(HttpClient), httpClient));
}
I'm attempting to add caching to our IS4 implementation using their Caching methods. However, my implementation does not appear to be having any impact on the speed of login or the number of queries hitting my database per login (which I would expect caching to reduce both).
The changes I made to implement caching are as follows:
Added the following to Startup.cs ConfigureServices
Updated the services.AddIdenttiyServer() call to include the lines:
.AddInMemoryCaching()
.AddClientStoreCache<IClientStore>()
.AddResourceStoreCache<IResourceStore>()
.AddCorsPolicyCache<ICorsPolicyService>();
Updated ConfigureServices to also have the following:
services.AddScoped<ICorsPolicyService, DefaultCorsPolicyService>();
services.AddScoped<IClientStore, ClientStore>();
services.AddScoped<IResourceStore, ResourceStore>();
That appeared to be the only things I needed to implement, and while the application runs normally, the caching does not seem to be doing anything. What am I missing?
Basically you need to do 2 things:
First implement the IClientStore:
public class ClientStore : IClientStore
{
private readonly IClientService clientService;
public ClientStore(IClientService clientService)
{
this.clientService = clientService;
}
public Task<Client> FindClientByIdAsync(string clientId)
{
var client = this.clientService.GetById(clientId);
return Task.FromResult(client);
}
}
The ClientService is my implementation for getting the client from the db, so there you need to put your own.
Then in the Startup.cs you need:
services.AddIdentityServer(options =>
{
options.Caching.ClientStoreExpiration = new TimeSpan(0, 5, 0);
})
.AddInMemoryCaching()
.AddClientStoreCache<ClientStore>()
.// More stuff that you need
This is for the Client Caching but for the Cors and the ResourceStore is quite the same.
I think that you are missing the options.Caching.ClientStoreExpiration part. Start from there.
Hope that this helps.
PS: Forgot to mention - you don't need to explicitly inject your implementation of the IClientStore. By adding it to the .AddClientStoreCache<ClientStore>() it gets injected. But (as in my example) if you have other services, used by the store, you need to inject them.
There is no standard way to cache users.
It caches only:
Clients - AddClientStoreCache
Resources - AddResourceStoreCache
CorsPolicy - AddCorsPolicyCache
More details you can get from documentations
I'm trying to use the new IHttpClientFactory with an ASP.net Core 2.1 WEB API application.
public void ConfigureServices(IServiceCollection services)
{
// other services configuration
services.AddHttpClient();
}
In my ConfigureServices method, I don't see a way to add the IHttpClientFactoryand configure it to use WinHttpHandler.
The AddHttpClient methods that return a IHttpClientBuilder gives you access to methods that configure the HttpMessageHandler but those have to be derived from DelegatingHandler but WinHttpHandler does not derive from DelegatingHandler.
See no way to tell HttpClient to use WinHttpHandler when being constructed.
Figured it out.
Thanks to tip given by #Nkosi in the comments!
I solved this by using a named HttpClient when registering the HttpClient service and then configuring the message handler to use WinHttpHandler as the PrimaryHandler
services.AddHttpClient<HttpClient>("WinHttp")
.ConfigureHttpMessageHandlerBuilder(c =>
{
c.PrimaryHandler = new WinHttpHandler() { WindowsProxyUsePolicy = WindowsProxyUsePolicy.UseWinInetProxy };
});
Then when using the IHttpClientFactory, specify the name you gave when registering it.
var httpClient = this._httpClientFactory.CreateClient("WinHttp");
Your HttpClient will now use WinHttpHandler!
NOTE
To use WinHttpHandler you must add nuget package System.Net.Http.WinHttpHandler