NETCore.Setup doesn't really integrates well into existing ecosystem

[POnakS]

I had high hopes for AWSSDK.Extensions.NETCore.Setup library, however ultimately it flips setup upside down. It doesn't really solve any problems, while adding its own.

I would expect, that this library builds on top of existing conventions (i.e. FallbackCredentialsFactory), however it does not - what's even worse, it implements its own credential/endpoint resolution system, which breaks your

Let's say you have existing app using MassTransit, among other things. MassTransit creates AmazonSqs instance by itself, and there is no options to integrate this library there.

To be more confusing, you have two different credential resolution systems - one used by AWS SDK (maybe you have even reconfigured that to use only what you need, and disable super confusing EC2 instance metadata credentials), and one from AWSSDK.Extensions.NETCore.Setup. You can kind of work around it by providing FallbackCredentialFactory.GetCredentails() to AwsOptions.Credentials, however you need to do it in every place you use AwsOptions, so it's not a robust solution.

Overall I would suggest to change the way this library works, and integrate into existing conventions (at least add its own resolver into FallbackCredentialFactory), to not confuse everyone by having multiple credential resolution systems. This applies to region endpoints / serviceUrls too.

[normj]

Hi @POnakS, sorry AWSSDK.Extensions.NETCore.Setup is not meeting your expectations.

I'm confused what you mean by it having its own credential resolution system? This library still uses FallbackCredentialsFactory or it's replacement in V4 DefaultIdentityResolverConfiguration to resolve credentials. It just happens to have a layer on top to look for credential configuration in the IConfiguration because the core part of the SDK would not have access to the instance of IConfiguration. If you are not configuring credentials via IConfiguration like have settings in the appsettings.json file then it uses the exact same mechanism for resolving credentials.

The idea of the library is to create instance of the service clients for the service interfaces using what ever configuration was given via IConfiguration. If a consumer has already created their instance of the service client like your MassTransit example I would expect them to register in the DI that instance of the service client for the service interface. You don't need this library to register an already instantiated service with a service interface in a DI container.

Apologize if I'm missing understanding question.