Closed CodingGorilla closed 6 years ago
You can beat this a couple different ways. You can either set up a rule to ignore those types in the type scanning, or just watch the registration ordering to call:
services.AddHttpClient<ISubscriptionsServiceClient, SubscriptionsServiceClient>()
.ConfigureHttpClient((sp, client) =>
{
var baseUrl = sp.GetRequiredService<IOptions<AuthServiceOptions>>().Value.SubscriptionServiceUri;
client.BaseAddress = new Uri(baseUrl, UriKind.Absolute);
})
after the type scanning, and Lamar will honor the registration order. Unlike SM, Lamar follows the ASP.net Core rule of "last registration wins"
I think my concern is that type scanning always happens after the framework calls ConfigureServices
, and based on instruction and examples from Microsoft you would normally add these registrations there in ConfigureServices
. So it's a bit counter-intuitive unless you know that you have to move those registrations down into the ConfigureContainer
(or write an excluding rule).
Would it not be better to prevent the duplicate registration? I mean if I manually register it, it seems reasonable to me that my manual registration would take precedence over an automatic registration.
You can do the call to AddHttpClient
in the ConfigureContainer() method. Or the ExcludeTypes
works no matter what order things are done in.
@CodingGorilla You'd need a custom convention in this case to understand that what they're doing should override what the type scanning is doing. I don't see this as general enough to build into Lamar itself.
So in my
ConfigureServices
I have the following:This is the new HttpClientFactory convention introduced in ASP.NET Core 2.1. Subsequently I have a
ConfigureContainer
method that looks like:It appears that the default convention scanning "overwrites" the previous registration from
ConfigureServices
as the configuration lambda is never fired, and indeed my injectedHttpClient
does not have the proper configuration. Checking the build plan for theISubscriptionServiceClient
produces the following:Changing the registration in
ConfigureServices
to use just the concrete type, rather than the interface/concrete pair behaves as I would expect (meaning the configuration from the factory is properly set).Moving the client registration into the
ConfigureContainer
method, after the scanning also solves the problem. Is this the expected behavior, should additional registrations not be done using theConfigureServices
method and rather have everything moved intoConfigureContainer
?