Adding a typed HTTP client twice, throws exception

[leastprivilege]

EDIT by @rynowak - see below for shiproom template.

Calling

services.AddHttpClient<SomeType>()

more than once throws an exception in 3.0 preview 7 - this used to work in 2.x.

Is that the intended behavior?

[rynowak]

This is intended to throw in 3.0 and the reason is that we've gotten lots and lots of bug reports where users would do things like this:

services.AddHttpClient<Foo.SomeType>().ConfigureSomething(...);
services.AddHttpClient<Bar.SomeType>().ConfigureSomethingElse(...);

These will result in all of the configuration being applied to a single logical client because http client factory uses named options based on the type name (not the fully-qualified type name).

It would be possible for us to make this work in the future if necessary. It's clear that how this actually works is different from what users believe. The change in 3.0 was made to make this problem clear when it occurs.

[leastprivilege]

So what's the recommendation then - this pattern seems common:

• a services.AddXXX extensions methods adds a bunch of services plus some default (typed) http clients
• this returns a builder
• the builder has some helpers to override the standard http clients

This is at least how we did it in IdentityServer. I am open to changing that.

[leastprivilege]

..oh and what's the reason to not use the fully qualified type name?

[rynowak]

So what's the recommendation then - this pattern seems common:

* a services.AddXXX extensions methods adds a bunch of services plus some default (typed) http clients

* this returns a builder

* the builder has some helpers to override the standard http clients

This is at least how we did it in IdentityServer. I am open to changing that.

This hasn't come up before so I don't have a ready-made solution for it. It makes sense.

[ImoutoChan]

What is expected behaviour when I do something like this:

services.AddHttpClient<ISomeInterface, SomeType>();
services.AddHttpClient<ISomeInterface, OtherType>();
services.AddHttpClient<ISomeInterface, OneMoreType>();

and then consume them with IEnumarable<ISomeInterface> in some constructor? This scenario worked fine before 3.0.

I found workaround and made it work like this:

services.AddHttpClient<SomeType>();
services.AddHttpClient<OtherType>();
services.AddHttpClient<OneMoreType>();

services.AddTransient<ISomeInterface>(provider => provider.GetRequiredService<SomeType>());
services.AddTransient<ISomeInterface>(provider => provider.GetRequiredService<OtherType>());
services.AddTransient<ISomeInterface>(provider => provider.GetRequiredService<OneMoreType>());

But it looks ugly.

[avandych]

These will result in all of the configuration being applied to a single logical client because http client factory uses named options based on the type name (not the fully-qualified type name).

But most of people used this in a proper way, for example we have a lot of different services which expose same API for metrics collection, we used single IMetricsClientApi interface implementation which was registered for each service available in catalog and that resolved in IEnumerable, we don't needed to know about each new service and add different implementations for each. Now we can't migrate to 3.0, we need to figure out how to reimplement this first.

[felschr]

I've encountered this issue in my integration tests using MicroserviceFactory where I'm overriding an existing HttpClient within builder.ConfigureTestServices with a different implementation that's to be used during the tests.