Include AWSSDK.SecurityToken in Lambda Test Tool runtime payload

[AlexDaines]

Summary

The packaged Amazon.Lambda.TestTool global tool does not ship AWSSDK.SecurityToken.dll. Whenever the SDK's credential chain inside the test tool process resolves to Amazon.Runtime.AssumeRoleAWSCredentials (profiles with role_arn, web-identity tokens, etc.), the SDK reflectively does Assembly.Load("AWSSDK.SecurityToken") to construct an STS client and the load fails with FileNotFoundException:

System.InvalidOperationException: Assembly AWSSDK.SecurityToken could not be found or loaded.
This assembly must be available at runtime to use Amazon.Runtime.AssumeRoleAWSCredentials.
 ---> System.IO.FileNotFoundException: Could not load file or assembly 'AWSSDK.SecurityToken, ...'
   at Amazon.Runtime.Internal.ServiceClientHelpers.GetSDKAssembly(String assemblyName)
   at Amazon.Runtime.AssumeRoleAWSCredentials.GetSTSClient(RegionEndpoint region)

The aspire integration's PlaygroundE2ETests.RunAWSAppHostProject hits this intermittently when its SQS event source background services start up inside the spawned test tool subprocess and the default credential chain lands on a profile-based AssumeRole. Sometimes the chain resolves to container/env-var credentials and the test passes; sometimes it falls through to a profile with role_arn and the test fails with the load error above. That is the source of the intermittent failures the DevEx team has been seeing.

Fix

Add a direct <PackageReference Include="AWSSDK.SecurityToken" Version="4.0.6.3" /> so the DLL ships in tools/<tfm>/any/ of the packed nupkg.

Verification

Built and packed locally with dotnet pack -c Release against the modified csproj. Confirmed:

• tools/net8.0/any/AWSSDK.SecurityToken.dll present (109,736 bytes)
• tools/net10.0/any/AWSSDK.SecurityToken.dll present (109,736 bytes)
• dotnet tool install from the local nupkg places the DLL alongside Amazon.Lambda.TestTool.dll, satisfying the runtime probe path

AWSSDK.Core side effect

Pulling in AWSSDK.SecurityToken 4.0.6.3 bumps the resolved AWSSDK.Core to the version that package requires (the other AWSSDK.* dependencies in the csproj resolved an older Core previously). Within the 4.0.x major, API-compatible. Visible in the packed nupkg: AWSSDK.Core.dll grows from 984,744 to 998,056 bytes.

Note on Lambda Test Tool V1

Tools/LambdaTestTool/src/Amazon.Lambda.TestTool/Amazon.Lambda.TestTool.csproj (the V1 tool) has the same packaging gap with V3 SDK packages. Not addressed in this PR since V1 is in maintenance and isn't the source of the current integ test failure. Worth a follow-up if V1 is still shipping.

Test plan

• Local pack: AWSSDK.SecurityToken.dll ships in net8.0 and net10.0 tool payloads
• Local install: DLL is in the runtime probe path of the installed tool
• CI build green
• Aspire integ test PlaygroundE2ETests.RunAWSAppHostProject passes consistently

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Ensures the Lambda Test Tool v2 global tool package includes AWSSDK.SecurityToken.dll so STS-based credential resolution (e.g., AssumeRoleAWSCredentials) does not fail at runtime due to reflective assembly loading.

Changes:

• Add a direct PackageReference to AWSSDK.SecurityToken so it ships with the packed tool payload.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[AlexDaines]

The csproj already spans multiple AWSSDK patch trains (Lambda 4.0.13.x, SQS/SSO 4.0.2.x, Extensions/SSOOIDC 4.0.3.x), so my addition follows the same "pin current-stable when updating" pattern the file already uses. Aligning everything to a single train is achievable but well outside the scope of fixing the AssumeRole crash. The transitive AWSSDK.Core bump from 4.0.6.3 is already documented in the PR description.

cc: @normj