Still having issues with AWS SDK v4

[blandis-turnberrysolutions]

🐛 Bug Description

What happened?
Upgraded AWS SDK to V4 and Localstack.Client / LocalStackClient.Extensions to 2.0. When setting useLocalStack true everything works fine. When setting useLocalStack false I get error saying it cannot find the constructor.

What did you expect to happen?
Both useLocalStack true and useLocalStack false should work.

🔄 Steps to Reproduce

1. Set useLocalStack to false in appsettings.json
2. dotnet run

[Minimal code example:]
(https://github.com/blandis-turnberrysolutions/localstack-client-extensions-repro)

📋 Environment Information

LocalStack.Client Version:

• v1.x (AWS SDK v3) - LTS Branch
• [X ] v2.x (AWS SDK v4) - Current Branch
• Version:

LocalStack Information:

• LocalStack Version:4.12.0
• LocalStack Image: localstack/localstack:4.12.0
• LocalStack Services Used: S3, SQS, EventBridge

.NET Information:

• .NET Version: 10.0.302
• Operating System: MacOS 26.6
• IDE/Editor: VS Code

AWS SDK Information:

• AWS SDK Version: 4.0
• Services: S3, SQS, EventBridge

🔍 Additional Context

Configuration (Optional):

// Your LocalStack configuration (appsettings.json snippet)
{
    "LocalStack": {
        "UseLocalStack": true,
        "Session": {
            "RegionName": "eu-central-1"
        },
        "Config": {
            "LocalStackHost": "localhost.localstack.cloud",
            "EdgePort": 4566
        }
    },
    "AWS": {
        "Profile": "<test>",
        "Region": "us-east-1"
    }
}

Error Messages/Stack Traces:

Unhandled exception. LocalStack.Client.Extensions.Exceptions.LocalStackClientConfigurationException: ClientFactory<T> missing constructor with AWSOptions parameter.
   at LocalStack.Client.Extensions.AwsClientFactoryWrapper.CreateServiceClient[TClient](IServiceProvider provider, AWSOptions awsOptions)
   at LocalStack.Client.Extensions.ServiceCollectionExtensions.<>c__DisplayClass12_0`1.<GetServiceFactoryDescriptor>b__0(IServiceProvider provider)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitFactory(FactoryCallSite factoryCallSite, RuntimeResolverContext context)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSiteMain(ServiceCallSite callSite, TArgument argument)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitRootCache(ServiceCallSite callSite, RuntimeResolverContext context)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSite(ServiceCallSite callSite, TArgument argument)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitConstructor(ConstructorCallSite constructorCallSite, RuntimeResolverContext context)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSiteMain(ServiceCallSite callSite, TArgument argument)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitRootCache(ServiceCallSite callSite, RuntimeResolverContext context)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSite(ServiceCallSite callSite, TArgument argument)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.Resolve(ServiceCallSite callSite, ServiceProviderEngineScope scope)
   at Microsoft.Extensions.DependencyInjection.ServiceProvider.CreateServiceAccessor(ServiceIdentifier serviceIdentifier)
   at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)
   at Microsoft.Extensions.DependencyInjection.ServiceProvider.GetService(ServiceIdentifier serviceIdentifier, ServiceProviderEngineScope serviceProviderEngineScope)
   at Microsoft.Extensions.DependencyInjection.ServiceProvider.GetService(Type serviceType)
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType)
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService[T](IServiceProvider provider)
   at Program.Main(String[] args) in /Users/bradleylandis/development/aws-test/Program.cs:line 30
   at Program.<Main>(String[] args)

✅ Checklist

• [X ] I have searched existing issues to ensure this is not a duplicate
• [X ] I have provided all the requested information above
• [X ] I have tested this with the latest version of LocalStack.Client
• I have verified this issue occurs with LocalStack (not with real AWS services)

[Blind-Striker]

Hey @blandis-turnberrysolutions,

It looks like AWSSDK.Extensions.NETCore.Setup 4.0.4 changed the ClientFactory<T> constructor from:

.ctor(AWSOptions awsOptions)

to:

.ctor(AWSOptions awsOptions, Action<ClientConfig, IServiceProvider> configAction)

I’ll update the constructor lookup to handle this change more gracefully. In the meantime, you can work around the issue by pinning AWSSDK.Extensions.NETCore.Setup to version 4.0.3.40.

[Blind-Striker]

@blandis-turnberrysolutions this is fixed and released — LocalStack.Client.Extensions 2.0.1 is on NuGet.org.

dotnet add package LocalStack.Client.Extensions --version 2.0.1

Nothing else to change — the public API is unchanged, and LocalStack.Client stays at 2.0.0.

What was actually wrong

Your instinct that something moved underneath was right, and it was not AWSSDK.Core — it was AWSSDK.Extensions.NETCore.Setup. Version 4.0.4 changed the internal ClientFactory<T> constructor:

// <= 4.0.3.40
internal ClientFactory(AWSOptions awsOptions)

// >= 4.0.4
internal ClientFactory(AWSOptions awsOptions, Action<ClientConfig, IServiceProvider> configAction = null)

The new parameter is optional, so from AWS's side this was source-compatible and shipped as a patch with nothing in the release notes. For our exact-signature reflection lookup it was binary-breaking, so client creation threw. Only the UseLocalStack: false path goes through that code, which is why it went unnoticed for ~70 days — LocalStack-only usage never reaches it.

Constructor resolution now matches on the AWSOptions parameter and defaults any trailing ones, so both the old and new shapes work, and a future appended parameter will not break it either. Failure messages also list the constructor signatures actually discovered, so if AWS does change something else it can be diagnosed straight from a report.

If you applied a workaround

If you pinned AWSSDK.Extensions.NETCore.Setup to 4.0.3.40, you can drop the pin. One thing to know: 2.0.1 raises the minimum to 4.0.100.5, so an explicit pin below that will now fail restore with NU1605. Removing the pin is the fix.

Verified

Reproduced your failure first, then confirmed the fix with a console app doing a real S3 create/list/delete round trip — against both LocalStack and live AWS, on AWSSDK.Extensions.NETCore.Setup 4.0.100.7, the version you were on:

Extensions	UseLocalStack: true	UseLocalStack: false
2.0.0	works	throws — this issue
2.0.1	works	works

A scheduled canary now builds against the newest AWSSDK.Core and AWSSDK.Extensions.NETCore.Setup daily, so the next time AWS changes something like this we find out before it reaches you.

Thanks for the report and especially for the minimal repro — it made the root cause obvious. Please reopen or file a new issue if anything is still off on your side.