Using HttpClientFactory without dependency injection

[poke]

Is there any way to consume the HttpClientFactory without using dependency injection, or more precisely without using M.E.DI?

I am creating a client library for which I want to make use of HttpClientFactory but I am going to use this library also in a legacy project that does not not have a M.E.DI-compatible DI.

Ideally, I would just new up a DefaultHttpClientFactory and consume that directly but since the factory itself is internal, this is not possible.

Why is the HttpClientFactory internal and is there any way to consume it explicitly without using DI?

[rynowak]

The answer to this really depends what you expect to get out of using the client factory. I get asked this question a lot, and the answer depends on a lot more details about what you want to accomplish. It sounds like you might have a few different scenarios so I'm providing a lot of information with the hopes that it's helpful.

If you are building a library that you plan to distribute, I would strongly suggest that you don't take a dependency on IHttpClientFactory at all, and have your consumers pass in an HttpClient instance.

If you are building a non-ASP.NET-Core application, consider using Microsoft.Extensions.Hosting to create a DI container.

If you are building a non-ASP.NET-Core application and you really don't want to use Microsoft.Extensions.Hosting then it depends what you want to use the client factory for.

A. I want an opinionated builder abstraction for configuring HttpClientFactory.
B. I don't need that. I just want an HttpClient with good network behavior by default.

If you are in category A then I have to explain that DI and IOptions<> is the opinionated builder abstraction. Everything in category A is built on top of DI and IOptions<>. The features exposed by the builder assume that you have a DI system, and we have no plans to try and separate these.

Based on the information you provided, I'm guessing you fall into category B.

If you are on .NET Core - you should use a single HttpClient directly and set SocketsHttpHandler.PooledConnectionTimeout here to an appropriate value.

If you are on .NET Framework - you should use a single HttpClient and use ServicePoint to configure the similar settings.

The good news for anyone interested in connection management is that .NET now has reasonable behavior on Linux (as of 2.1 and SocketsHttpHandler) but it requires configuration.

[rynowak]

I've logged a doc issue to clear this up further. dotnet/AspNetCore.Docs#11882

[poke]

Thank you for the detailed answer (and that doc request), that is going to help a lot!

In my case, I’m somewhere between A and B actually. The client library I am working on is mostly targeted to ASP.NET Core applications, so I have a helper extension method on the service collection that just adds all the clients as typed clients using the HttpClientFactory (using a custom options object to configure a few parameters). That is working just fine the way it is.

However, I now have the requirement to use this in a legacy ASP.NET application that uses Autofac as DI container. So I cannot really use any M.E.DI-specific stuff, and I certainly don’t want to bring all the stuff into that project just to use the HttpClientFactory.

Ideally, what I would like to do is to set up a HttpClientFactory, configure a few clients and then have something I can call to create a factory method that I then register with the existing DI container. What you say makes sense though; the factory makes heavy use of DI and options, so using it without it would be really difficult.

In my case, the various clients each have different DelegatingHandlers that are configured ahead, so using a single HttpClient will not really work for me. But I guess I will just have to set up separate HttpClient instances then for each client.

If you are on .NET Framework - you should use a single HttpClient and use ServicePoint to configure the similar settings.

It would be really nice if there was some guidance along with the docs on what would be good defaults for setting up a HttpClient.

[davidfowl]

However, I now have the requirement to use this in a legacy ASP.NET application that uses Autofac as DI container. So I cannot really use any M.E.DI-specific stuff, and I certainly don’t want to bring all the stuff into that project just to use the HttpClientFactory.

Sure you can, in this mode, think of M.E.DI stuff as an implementation detail for how to get an IHttpClientFactory instance. The other features though, rely on this internal detail in order to do more complex things (like typed clients etc).

Alternatively, if you really wanted to try to integrate the 2 things (autofac and the HttpClientFactory), you can use the ServiceCollection as the configuration API for the HttpClient and use Autofac.Extensions.DependencyInjection to wire it up to your existing autofac container:

public class MyTypedClient
{
    public MyTypedClient(HttpClient client)
    {

    }
}

public class Program
{
    public static void Main(string[] args)
    {
        var services = new ServiceCollection();
        services.AddHttpClient()
                .AddHttpClient<MyTypedClient>();

        var containerBuilder = new ContainerBuilder();
        containerBuilder.Populate(services);
        var container = containerBuilder.Build();
        var factory = container.Resolve<IHttpClientFactory>();
        var typedClient = container.Resolve<MyTypedClient>();
    }
}

It would be really nice if there was some guidance along with the docs on what would be good defaults for setting up a HttpClient.

+1

[uhaciogullari]

Hey everyone

I've made a fork to address this issue.
https://github.com/uhaciogullari/HttpClientFactoryLite
Let me know what you think.

[alexeyzimarev]

A. I want an opinionated builder abstraction for configuring HttpClientFactory.
B. I don't need that. I just want an HttpClient with good network behavior by default.

I'd like to stress out that using the DI container for absolutely everything is not the best example of design. Insisting that all developers need to use the container for things like HTTP client factory, in-memory cache, distributed cache, logging and so on, creates impediments for developers that would otherwise avoid using DI containers altogether. I personally prefer to construct my dependency tree in the Startup class explicitly and don't rely on something else that I don't control to resolve dependencies for me.

There's was an issue dotnet/extensions#615 for using ILogger without the container and it is fixed for .NET Core 3. I would expect that all other factories would follow the same approach and expose a way to instantiate factories without using the container, at least for the reason of consistency.

[SittenSpynne]

I also feel like this seems like a strange way to strongarm people out of using other DI containers.

I maintain Xamarin Forms projects that predate the M.E.DI stuff. One uses TinyIoC because it chose the FreshMVVM framework. The other uses AutoFac. It would be a PITA for me to rework them to use the Microsoft DI container. I shouldn't have to in order to use HttpClient.

In the AutoFac project, I'd like to reuse a REST utility someone else made for interacting with an internal web service. That utility was written in an ASP .NET Core environment so it already expects me to give it an HttpClient. So he's using the Web Host container and gets all the stuff I want for free.

I don't see good guidance for how to configure AutoFac to do the same thing your DI does. I do see a kind of janky path to set up the M.E.DI container, then somehow convert that to AutoFac. That feels ridiculous. I get that HttpClientFactory is opinionated, but I don't think part of that opinion should be "your app must use Microsoft DI".

Especially in the Xamarin context, I'm bewildered. I've scanned a few articles and issues related to this and I can't tell if I should or shouldn't be using IHttpClientFactory at all. Some seem to suggest I should just set SocketsHttpHandler properties, but that's not available in Xamarin. Some articles vaguely gesture at whether I should configure Xamarin project properties to use platform-specific handlers.

I don't see a clear message for how devs outside of ASP .NET Core are supposed to use HttpClient. I thought when I found this library it would be the clear message. But it looks like even within this library, I see confusing comments that imply outside of ASP .NET Core I might not even want to use HttpClientFactory. Even if that was the wrong read, I don't see an explanation for what the magic inside M.E.DI is so I can realize it with a different DI container (or no container at all.)

If Generic Host container isn't suitable for all platforms, where is the documentation that outlines its limitations and explains, for every Microsoft-supported platform, what the best practice for using HttpClient is? I shouldn't have to read half a dozen blogs to understand such a crucial type, it should be explained by MS.

[kierenj]

Incidentally AutoFac has MS DI integration - I think it boils down to a one-liner (builder.Populate(services);).

That said, we went ahead with AutoFac for many internal projects but are struggling to see any advantage to it considering all MS packages use IServiceCollection etc. There's a big old GH issue I have somewhere to remove it just to avoid that one extra step..

[disklosr]

I have a net core unit test project without DI and having a static HttpClientFactory would have been handy to build a HttpClient with many handlers in a one liner using HttpClientFactory.Create(params DelegatingHandler[] handlers)

[JHeLiu]

A. I want an opinionated builder abstraction for configuring HttpClientFactory.
B. I don't need that. I just want an HttpClient with good network behavior by default.

I'd like to stress out that using the DI container for absolutely everything is not the best example of design. Insisting that all developers need to use the container for things like HTTP client factory, in-memory cache, distributed cache, logging and so on, creates impediments for developers that would otherwise avoid using DI containers altogether. I personally prefer to construct my dependency tree in the Startup class explicitly and don't rely on something else that I don't control to resolve dependencies for me.

There's was an issue dotnet/extensions#615 for using ILogger without the container and it is fixed for .NET Core 3. I would expect that all other factories would follow the same approach and expose a way to instantiate factories without using the container, at least for the reason of consistency.

You are absolutely right that dependency injection is not everything I need. Sometimes dependency injection is more cumbersome and increases my workload. It seems useful but it is meaningless, 666

[sln162]

Is it possible to use the app.ApplicationServices.GetService() in the Configure method to get the IHttpClientFactory, then assign it to public static, and then globally.
Using this, I wrote an HttpHelper, which is just a static IHttpClientFactory, which is currently used without problems.
Do not know if there are hidden dangers, or will this follow-up support?
@rynowak

[rynowak]

Is it possible to use the app.ApplicationServices.GetService() in the Configure method to get the IHttpClientFactory, then assign it to public static, and then globally.

I'm sure you can do this, and I'm sure that the code will work.

However you're baking in a dependency on a global static. Do you really want to do that? Will you ever want to test any of that code?

[sln162]

Is it possible to use the app.ApplicationServices.GetService() in the Configure method to get the IHttpClientFactory, then assign it to public static, and then globally.

I'm sure you can do this, and I'm sure that the code will work.

However you're baking in a dependency on a global static. Do you really want to do that? Will you ever want to test any of that code?

Thank you for your help. Our code is converted from asp.net. Not only httpclient needs to be called in the controller, but also in many classes. It's not easy to rely on the injection method, so I made a global static, maybe I didn't find a better way.

[MelbourneDeveloper]

Which NuGet, assembly and namespace is this mythical HttpClientFactory class located in? I can't find it anywhere...

[rynowak]

package API