MS article on why you should not be managing your HttpClient manually and instead use IHttpClientFactory. See here for line that should be updated.
Important tidbits here:
"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."
"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."
MS article on why you should not be managing your
HttpClientmanually and instead useIHttpClientFactory. See here for line that should be updated.Important tidbits here:
"Another issue that developers run into is when using a shared instance of
HttpClientin long-running processes. In a situation where theHttpClientis 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.""Though this class implements
IDisposable, declaring and instantiating it within a using statement is not preferred because when theHttpClientobject 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 usingHttpClientwrong and it's destabilizing your software."