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

Recently, I conducted a deep review of the AWS SDK for .NET, and the results were disappointing. I gave it an overall grade of D. To be fair, I wanted to apply the same level of scrutiny to Microsoft’s own offering, starting with the Azure Core SDK.

My goal is simple: understand the real state of its code quality and identify the risks that .NET developers inherit when adopting it. Unfortunately, what I found was just as concerning.

The Scope of the Azure Core SDK

The Azure Core SDK consists of 257 individual solutions, targeting a wide range of .NET versions, including .NET 10.

Unlike the AWS SDK, which is provided as a single massive solution, each Azure SDK project lives in its own solution. Analyzing all 257 projects would have taken an unreasonable amount of time, so I selected six representative projects to evaluate overall quality and consistency.

These six projects were more than enough to expose the underlying patterns and systemic issues within the SDK. However, I immediately ran into another serious problem: I could not build any of these solutions. Even worse, I could not find any documentation explaining how to build them.

That is a major red flag.

Any open-source project, especially one as widely used and critical as the Azure SDK, should be easy to build or, at the very least, provide clear and accurate build instructions in its README. A project that cannot be built easily cannot be validated or tested.

If developers cannot reproduce the build, they cannot verify fixes, evaluate quality, or confidently contribute. This alone undermines transparency and weakens confidence in the entire SDK.

Code Quality Statistics

Below are the solutions I reviewed. Sadly, the Azure SDK suffers from many of the same systemic problems seen in the AWS SDK. I had hoped for better, given that this is Microsoft’s own platform, but the results were deeply disappointing.

The biggest concerns are:

• Extremely large numbers of code violations
• Widespread blocks of cloned code
• Inadequate unit testing
• Dangerous misuse of IDisposable
• Performance anti-patterns
• No real globalization support

Azure.ResourceManager.Advisor

• 7,317 total violations
• 52 blocks of cloned code
• Cyclomatic Complexity: 2,413
• Unit Tests: 31

Azure.AI.AgentServer

• 16,006 total violations
• 362 blocks of cloned code
• Cyclomatic Complexity: 14,514
• Unit Tests: 6

Azure.ResourceManager.CloudHealth

• 6,880 total violations
• 97 blocks of cloned code
• Cyclomatic Complexity: 4,317
• Unit Tests: 51

Azure.ResourceManager.CosmosDB

(Lower violation counts due to analyzer failures)

• 11,501 total violations
• 1,141 blocks of cloned code
• Cyclomatic Complexity: 25,491
• Unit Tests: 487

Azure.Core

• 200,833 total violations
• 532 blocks of cloned code
• Cyclomatic Complexity: 114,605
• Unit Tests: 2,532

Azure.Messaging.ServiceBus

• 73,456 total violations
• 220 blocks of cloned code
• Cyclomatic Complexity: 5,005
• Unit Tests: 776

Common Code Quality Problems

These issues appeared repeatedly across all projects:

• Expression results are never used
• Formatting violations
• Poor object-oriented design
• Inadequate null checks
• Initializing variables to default values unnecessarily
• Locking on objects with weak identity
• Missing accessibility modifiers
• Missing braces in if statements
• Folder structures not matching namespaces
• Nested types
• No globalization support
• Improper async usage
• Strings not placed in resources
• Types not sealed
• Fields not marked readonly
• Public fields
• Incorrect collection return types
• Spelling errors
• Unnecessary using statements
• Unreachable code
• Unused fields and parameters
• Incorrect accessibility modifiers
• Improper type choices

These are not edge cases. They indicate systemic neglect of basic coding standards.

Serious Design and Resource Management Issues

IDisposable Misuse

This is by far the most dangerous category of problems:

• Dispose() methods that do nothing
• Improper IDisposable implementations
• Missing GC.SuppressFinalize()
• Classes containing disposable fields but not implementing IDisposable
• Objects that are never disposed at all

This guarantees memory leaks and resource exhaustion in long-running systems.

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

For this reason alone, I would be extremely cautious about using parts of this SDK in production environments without heavy internal validation.

Other Major Issues

• Minimal and ineffective .editorconfig
• Poor naming consistency
• Lack of parameter validation

These make the SDK brittle, difficult to consume, and risky for global applications.

Performance Anti-Patterns

The SDK also shows numerous performance issues, including:

• Not using Length for arrays
• Using Random instead of RandomNumberGenerator
• Not using GeneratedRegexAttribute
• Not using LibraryImportAttribute

These directly impact throughput, memory usage, and runtime efficiency.

What This Means for .NET Developers

The Azure SDK is widely trusted, but it carries substantial technical debt:

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

Popularity does not equal quality.

Final Thoughts

I gave the Azure Core SDK an overall grade of C because of:

• The sheer number of violations
• Dangerous handling of disposable resources
• Weak unit testing practices

If your applications or services interact heavily with Azure and you are experiencing memory pressure or stability problems, now you have a likely explanation.

Maybe companies like Microsoft should rethink letting AI write reportedly 30% of their code. AI is a junior programmer at best—except with zero real-world experience, no judgment, and no accountability when things go wrong.

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

I’d like to reiterate that the number of code violations may actually be lower than what I reported. Unfortunately, I was unable to get the provided solutions to compile successfully, which prevented a complete and accurate analysis. As a result, the findings presented here should be considered a best-effort evaluation based on the portions of the code that could be reviewed.

Never blindly trust open-source packages.
Always review what you depend on.

Their problems become your problems.

If you would like me to review an open-source project you rely on, email me at: dotnetdave@live.com

Azure SDK: https://github.com/Azure/azure-sdk-for-net

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.