Inside the AWS SDK for .NET: A Code Quality Wake-Up Call

Do you truly understand the quality of the NuGet packages your projects rely on?

It has been some time since I last conducted a thorough code review of a major open-source project. Since the AWS SDK is one of the most downloaded packages on NuGet, I decided it was time to take a deeper look.

I had briefly reviewed the SDK in the past, but this time I wanted a much more thorough examination. My goal was to understand the real state of the code quality and identify the risks .NET developers inherit when using it. Unfortunately, what I found was deeply concerning.

The Scope of the AWS SDK

The AWS SDK solution consists of 442 projects. Most target .NET Standard, while the service projects also target:

• netstandard2.0
• netcoreapp3.1
• net8.0

This immediately creates performance and compatibility concerns for modern .NET projects such as .NET 10.

Simply running code analysis and metrics was painful:

• Visual Studio memory usage exceeded 20 GB
• The IDE spent long periods in Not Responding
• Several analysis tools failed entirely

That alone is a warning sign.

Tooling and Analysis Challenges

Because of the solution size, Visual Studio 2022 struggles badly:

• Calculating code metrics takes an extremely long time
• Exporting metrics to Excel frequently fails
• The full solution is impossible to work with as a single unit

I had to split the solution into two:

1. Core assemblies
2. Services projects

Even then:

• Excel could not export metrics for the Services solution
• CodeRush and NDepend failed
• NDepend could not build the solution
• Build instructions were nowhere to be found
• PowerShell scripts did not work

Unfortunately, NDepend relies entirely on its own proprietary code-violation analysis engine and does not integrate with Visual Studio’s EditorConfig-based analyzers. Because of this separation, it cannot reflect the same ruleset or diagnostics that Visual Studio produces. For that reason alone, I was unable to use NDepend to generate a truly comprehensive and consistent analysis for this project.

I spent over four days just trying to collect partial data. The numbers below are likely to be better than reality.

Core Solution: Code Quality Statistics

Code Analysis

• 54,835 total violations
  • 4,818 Errors
  • 50,017 Messages
• 710 blocks of cloned code
  A massive long-term maintenance problem.

Code Metrics

• Maintainability Index:
  • Average: 91.6 (not bad)
  • Worst cases: 18 (very bad)
  • 14,055 members have low maintainability
• Cyclomatic Complexity:
  • Total: 8,810
  • Unit tests: 763
  • Over 8,000 missing tests just to cover cyclomatic complexity
  • Worst method: complexity of 54 with zero tests
• Depth of Inheritance:
  • Generally low (good), but
  • 34 types in danger range
• Class Coupling:
  • 184 types indicate serious design issues
• Executable Lines of Code:
  • 12,497 lines
  • One violation every 4.4 lines of code
    This is extremely poor.

Services Solution: Alarming Numbers

These are only partial results:

• 904,980 total violations
  • 166,225 Errors
  • 757 Warnings
  • 737,998 Messages
• 12,369 blocks of cloned code
  Mostly from generated code, but still devastating for maintainability.

These are the highest violation counts I have ever seen in my career.

Common Code Quality Problems

Recurring issues include:

• Missing accessibility modifiers
• Expression results are never used
• Formatting violations (tens of thousands)
• Hard-coded URLs and configuration values
• Missing braces in if statements
• Fields not marked readonly
• Improper collection return types
• Unnecessary using directives
• Misspelled identifiers
• Incomplete switch statements
• Nested public types
• Incorrect type usage (string instead of Uri, etc.)

These represent systemic neglect of basic coding standards.

Serious Design and Resource Management Issues

IDisposable Misuse

This was by far the most dangerous issue:

• Types implementing IDisposable without disposable fields
• Types using disposable objects without implementing IDisposable
• Dispose() methods that do nothing
• Objects are not being disposed of at all

This guarantees memory leaks and resource exhaustion.

.NET has existed for over 25 years. There is no excuse for this.

For this reason alone, I would be extremely cautious about using this SDK in production.

Other Major Issues

• No EditorConfig file for enforcing standards
• Poor naming consistency
• No parameter validation
• Extremely poor encapsulation
• Outdated and deprecated NuGet packages
• Catching Exception instead of specific exceptions
• Swallowing exceptions
• Improper use of throw that destroys stack traces
• No globalization support (messages, string comparisons, etc.)

This makes the SDK unfriendly and risky for global usage.

Performance Anti-Patterns

Not Using TryGetValue

if (_settingsDictionary.ContainsKey(type))
    return _settingsDictionary[type];

Should be:

if (_settingsDictionary.TryGetValue(type, out var settings))
{
   return settings;
}

This is 1.7× faster and avoids double lookups.

Constant Array Arguments

Instead of:

resource.Split(new[] { ':', '/' });

Use:

private static readonly char[] ResourceSeparators = { ':', '/' };

// Then in method
resource.Split(ResourceSeparators);

This is 1.38× faster and avoids unnecessary allocations.

What This Means for .NET Developers

This SDK is widely trusted, but it carries significant technical debt:

• Performance risks
• Memory leaks
• Design flaws
• Maintainability issues

Popularity does not equal quality.

Final Thoughts

The AWS SDK for .NET shows what happens when standards are ignored at scale.
It also exposes serious weaknesses in Visual Studio’s ability to analyze large solutions. All code analysis tools should:

• Be more reliable
• Support Excel or Json export
• Avoid crashing or freezing

My next review will be the Azure Core project.
Register on the site if you want to be notified.

The code analysis for this article was performed using my custom .editorconfig file, which contains more than 1,000 carefully curated code analysis rules. These settings are derived directly from the recommendations in my Coding Standards and Code Performance book and represent the same standards I apply to production-grade .NET projects.

This configuration enforces best practices for code quality, maintainability, reliability, and performance, ensuring that every issue identified is grounded in proven engineering principles, not arbitrary defaults.

You can review the complete configuration here:
https://bit.ly/dotNetDaveEditorConfig

Never blindly trust open-source packages. Always review them.
Their problems become your problems. If you’d like me to review an open-source project you rely on, email me at:
dotnetdave@live.com

Pick up any books by David McCarter by going to Amazon.com: http://bit.ly/RockYourCodeBooks

If you liked this article, please buy David a cup of Coffee by going here: https://www.buymeacoffee.com/dotnetdave

© The information in this article is copywritten and cannot be preproduced in any way without express permission from David McCarter.