I use HttpClient library with reusing instance: I create instance in cunstructor like m_HttpClient = new HttpClient(); and then use this instance through life of my app. Everything work fine till user, who use this app, change network (change ethernet to wifi etc ....). After this change next communication with server cause app crash (without exception or log message in Event system of Windows). When I dispose HttpClient object and recreate it, problem is solved, but I lost advantage of reusing HttpClient object.
I use HttpClient in netstandard 2.0 library, which is called from netframework 4.7.2. app.
Is it standard behavior of this library? Or what I am doing bad?
Sorry for my English, thx.
Dot Net design guidelines says you should use IHttpClientFactory to implement resilient HTTP requests instead of using IHttpClient directly. It will internally have a pool of instances which has the efficient reusing logic.
Also, use polly also for retrying (if needed) as changing the network will be a failure and in Another issue that developers run into is when using a shared instance of HttpClient in long-running processes. In a situation where the HttpClient is instantiated as a singleton or a static object, it fails to handle the DNS changes as described in this issue of the dotnet/runtime GitHub repository.
Most of the info is from microsoft docs, I have picked and quoted the important info in this answer. You can read this blog for info. link
Though this class implements IDisposable, declaring and instantiating it within a using statement is not preferred because when the HttpClient object gets disposed of, the underlying socket is not immediately released, which can lead to a socket exhaustion problem. For more information about this issue, see the blog post You're using HttpClient wrong and it's destabilizing your software.
Polly is a transient-fault-handling library that helps developers add resiliency to their applications, by using some pre-defined policies in a fluent and thread-safe manner.
Benefits of using IHttpClientFactory
The current implementation of IHttpClientFactory, that also implements IHttpMessageHandlerFactory, offers the following benefits:
Provides a central location for naming and configuring logical HttpClient objects. For example, you may configure a client (Service Agent) that's pre-configured to access a specific microservice. Codify the concept of outgoing middleware via delegating handlers in HttpClient and implementing Polly-based middleware to take advantage of Polly's policies for resiliency. HttpClient already has the concept of delegating handlers that could be linked together for outgoing HTTP requests. You can register HTTP clients into the factory and you can use a Polly handler to use Polly policies for Retry, CircuitBreakers, and so on. Manage the lifetime of HttpMessageHandler to avoid the mentioned problems/issues that can occur when managing HttpClient lifetimes yourself.
I hope this helps you in finding answers for you.