The AWS SDK for .NET enables .NET developers to easily work with [Amazon Web Services][aws] and build scalable solutions with Amazon S3, Amazon DynamoDB, Amazon Glacier, and more.
- [API Docs][docs-api]
- [AWS .NET Developer Blog][dotnet-blog]
- [SDK Homepage][sdk-website]
- SDK Developer Guide
- [Forum][sdk-forum]
- [GitHub Issues][sdk-issues]
- SDK Samples
Please use these community resources for getting help. We use the [GitHub issues][sdk-issues] for tracking bugs and feature requests and have limited bandwidth to address them.
- Ask a question on StackOverflow and tag it with aws-sdk-net
- Come join the AWS .NET community chat on gitter
- Open a support ticket with AWS Support
- If it turns out that you may have found a bug, please open an [issue][sdk-issues]
If you encounter a bug with AWS SDK for .NET we would like to hear about it. Search the existing issues and try to make sure your problem doesn’t already exist before opening a new issue. It’s helpful if you include the version of AWS SDK .NET and the OS you’re using. Please include a stack trace and reduced repro case when appropriate, too.
The [GitHub issues][sdk-issues] are intended for bug reports and feature requests. For help and questions with using AWS SDK for .NET please make use of the resources listed in the Getting Help section. There are limited resources available for handling issues and by keeping the list of open issues clean we can respond in a timely manner.
The change log for the SDK can be found in the SDK.CHANGELOG.ALL.md file. Change logs divided up by year can be found in the changelogs folder.
For information about maintenance and support for SDK major versions and their underlying dependencies, see the following in the AWS SDKs and Tools Shared Configuration and Credentials Reference Guide:
With version 3 of the AWS SDK for .NET the SDK has been modularized. This means a separate NuGet package is created for each service as well as a core project. To use this branch compile the solution in the sdk folder that matches the desired platform and then include the assemblies for the services needed as well as the core assembly.
The AWS SDK for .NET uses a 4 part versioning scheme following the pattern of w.x.y.z.
- w - Incremented for code breaking changes.
- x - Incremented for binary breaking changes. In particular this is used to identitfy what versions of AWSSDK.Core are binary compatible with the service packages. For example if AWSSDK.SQS version 3.3.1.0 came out today when the current version of AWSSDK.Core is 3.3.17.5 then AWSSDK.SQS 3.3.1.0 would be compatible with all versions of AWSSDK.Core starting from 3.3.17.5 up to but not including a future 3.4.0.0.
- y - Incremented for a new SDK feature, like new credential management, or an AWS service update.
- z - Incremented for a bug fix or for service packages to update to the latest AWSSDK.Core to pull in latest bug fixes.
The SDK assemblies are strongly named which requires consumers of the SDK to recompile every time the AssemblyVersion attribute is incremented. To avoid forced recompilations the AssemblyVersion only contains the w.x portion of the version. The full w.x.y.z version number is set in the AssemblyFileVersion attribute which is not part of the strong name.
Classes and interfaces with Internal in the namespace name are logically internal to the SDK but are often marked with a public access modifier, generally to allow the service-specific packages to use shared functionality in the Core package. Classes and interfaces in these namespaces are subject to modification or removal outside of versioning scheme described above. If you find yourself relying on Internal functionality directly, consider opening a Feature Request for your use case if one does not already exist.
Each service package includes a code analyzer that's automatically included when installing from NuGet. These analyzers are created based on the rules from the service model, and will generate a warning if you use a property value that's not valid (for example, shorter than the minimum length expected by the service).
Starting with the 3.7.200 versions of the AWS SDK for .NET NuGet packages, the analyzers target .NET Standard 2.0 and support Visual Studio 2019 RTM and later (announcement: #2998).
Users on Visual Studio 2017 (or earlier) can still use new versions of the SDK, but there'll be a new warning (CS8032) about analyzers failing to run. If the build system is configured to treat warnings as errors, this new warning will need to be suppressed or ignored (using WarningsNotAsErrors).
Starting with version 3.5 of the AWS SDK for .NET, projects using Unity 2018.1 or later should target the .NET Standard 2.0 release of the SDK. You can find additional information in the developer guide: Unity support and Migrating your Unity application.
You can find the archive for legacy Unity support at https://github.com/aws/aws-sdk-unity-net.
This SDK has optional functionality that requires the AWS Common Runtime (CRT) bindings to be included as a dependency with your application. This functionality includes:
- Amazon S3 Multi-Region Access Points
- Amazon S3 Object Integrity
- Amazon EventBridge Global Endpoints
If the required AWS Common Runtime components are not installed you will receive an error like Attempting to make a request that requires an implementation of AWS Signature V4a. Add a reference to the AWSSDK.Extensions.CrtIntegration NuGet package to your project to include the AWS Signature V4a signer.,
indicating that the required dependency is missing to use the associated functionality. To install this dependency follow
the provided instructions.
Add a reference to the NuGet package AWSSDK.Extensions.CrtIntegration to your project.
Important: Do not run the integration tests on a production account.
Integration tests can be found in the AWSSDK.IntegrationTests project. These test assume that a default profile has been configured for credentials. For information about setting up a default profile read the [Developer Guide][credentials-management].
The tests are designed to create and delete the resources needed for testing but it is important to keep your data safe. Do not run these tests on accounts that contain production data or resources. Since AWS resources are created and deleted during the running of these tests, charges can occur. To reduce charges occurred by running the tests the test focus on AWS resources that have minimal cost.
Unit tests can be found in the AWSSDK.UnitTests project.
Protocol tests can be found in the sdk/test/ProtocolTests directory. Protocol tests ensure that each AWS protocol is working as expected. Each supported protocol is listed here. These tests are safe to run as they do not call real AWS services. You can run these tests by either opening the solution file and running the tests or via the dotnet cli by invoking dotnet test AWSSDK.ProtocolTests.NetStandard.csproj. The structure for the protocol test cases can be found here in the smithy docs.
- AWSSDK.S3
- Amazon Simple Storage Service (Amazon S3), provides developers and IT teams with secure, durable, highly-scalable object storage.
All low-level service clients are created using the code generator found in the generator folder. The code generator uses the service models defined in the generator\ServiceModels folder.
