The AWS SDK for .NET is an open source project available on GitHub. This post is to help community developers navigate the SDK code base with an eye toward contributing features and fixes to the SDK.
The first gotcha for contributors is that major portions of the code are generated from models of the service APIs. In version 3 of the SDK, we reorganized the code base to make it obvious which code is generated. You'll now find it under each service client folder in folders named "Generated." Similarly, handwritten code is now found in folders named "Custom." Most of the generated code is in partial classes to facilitate extending it without having changes get clobbered by the code generator.
The convention we use when adding extensions to generated partial classes is to place a file called Class.Extensions.cs under the Custom folder with the same hierarchy as the generated file.
The code generator can be found here. The models are under the ServiceModels folder. To add a client, add a model to the ServiceModels folder, update the
_manifest.json file in the same folder, and run the generator. The customization files in the folder handle ways in which we can override the behavior of the generator, mostly to keep some consistency across older and newer services, as well as make adjustments to make the API more C#-friendly.
It is sometimes necessary to update the code generator to add a feature or fix an issue. Because changes to the generator may impact all existing services and require a lot of testing, these changes should not be undertaken lightly.
Another thing you may notice about the code base is that some files are under folders like
_async. This is how the SDK controls which files are included in platform-specific project files.
As an example, if you look at the AutoScaling client folder you will see the folders
Model _bcl35 _bcl45 _mobile
_bcl45 folder contains the Auto Scaling client and interface for version 4.5 of the AWS SDK for .NET. It differs from the 3.5 version in that it exposes Async/Await versions of the service APIs, where the 3.5 version exposes Begin/End for asynchrony. The Model folder contains code common to all platforms. For this reason, don't use Visual Studio to add files to an SDK project. Instead, add the file to the appropriate file system location, and then reload the project. We try to use this subdirectory mechanism rather than
#if directives in the code where possible.
It will be much easier to evaluate and provide feedback on contributions if they are accompanied by unit tests, which can be added to the UnitTests folder.
Sometimes it is good to include some integration tests that hit the service endpoint, too. Integration tests will, by necessity, create AWS resources under your account, so it's possible you will incur some costs. Try to design integration tests that favor APIs that don't create resources, are fast to run, and account for the eventual consistency of the APIs you're testing.
Community Feature Requests
Many contributions are driven by the specific needs of a community member, but sometimes they're driven simply by a desire to get involved. If you would like to get involved, we collect community feature requests in the
FEATURE_REQUESTS.md at the top level of the repository.