Introduction to dotnet/extensions repo

You have probably been in this situation: your microservice works great on your computer. It passes every test, the tests that check how different parts work together are all good and the user interface is really fast.
But then, it hits the real world - a distributed cloud environment where networks are flaky, data privacy laws are strict, and 99.9% uptime is the baseline expectation, not a goal.

This is what we call the Production-Ready Gap. While the main .NET runtime gives you the parts making a strong and safe system needs more. That extra something is often found in the dotnet/extensions repository.

Why are they created?

If you have worked with ASP.NET Core you are already familiar with Microsoft.Extensions for things like Dependency Injection and Logging and Configuration.
However dotnet/extensions is different. You can think of it as Hardened Layer the part of the.NET ecosystem.

These libraries were born from the internal requirements of Microsoft’s largest services, like Microsoft Teams and Microsoft 365.
They aren't just utility functions; they are battle-tested implementations of cloud-native patterns designed to handle massive scale and strict compliance.
The idea is that dotnet/extensions is like a foundation for the.NET ecosystem and it helps with things, like Dependency Injection and Logging and Configuration.

Nine problems, nine solutions

The repo is organized around nine functional areas.
Each one is independently installable as a NuGet package, so you can adopt them à la carte without pulling in the whole thing.

AI

The Microsoft.Extensions.AI packages define a set of provider-agnostic interfaces for working with generative AI:

• IChatClient — a standard interface for chat completions, whether you're talking to OpenAI, Azure OpenAI, Ollama, or anything else
• IEmbeddingGenerator<TInput, TEmbedding> — the same idea for embedding generation
• IImageGenerator — image generation from text prompts

The key insight is that these are just interfaces. Any library that wants to participate in the ecosystem implements them. You write your app code against the interface, and you swap providers by changing one DI registration. Semantic Kernel and the .NET Agent Framework both build on top of these abstractions.

On top of the interfaces, there's a middleware pipeline system. You can compose caching, logging, OpenTelemetry tracing, and automatic function invocation into your AI client using a fluent builder - the same mental model as ASP.NET Core middleware, applied to your LLM calls.

Resilience

If you've used Polly before, this one will feel familiar - because it's built on Polly.
Microsoft.Extensions.Http.Resilience gives you a "standard resilience pipeline" that you add to any HttpClient in one line.
Under the hood it stacks: total request timeout → per-attempt timeout → retry → rate limiter → circuit breaker.

There's also a hedging pipeline, for scenarios where you're calling multiple endpoints and want to automatically fall back to healthy ones when some are degraded. The circuit breakers are keyed by URL authority, so each endpoint gets its own isolation boundary. The telemetry enrichment is included automatically.
Every time a resilience event fires (a retry, a circuit break), the relevant dimensions get added to your outgoing metrics without any extra code.

Telemetry

• Enhanced logging:
  The package ships a custom source generator that replaces the default .NET LoggerMessage generator. It knows how to log the contents of collections, not just ToString() on them. It also adds [LogProperties], an attribute you put on a complex object parameter that tells the generator to walk its public properties and log them as individual structured key-value pairs.
• Latency context:
  You register named checkpoints, measures, and tags at startup, then mark them at runtime as requests flow through your service. At the end of each request, a middleware flushes all of it to a registered exporter.
• Log sampling:
  Reduce the volume of log data sent to backend systems

Compliance

A framework helps mark information in data. It also generates audit reports and removes sensitive data(useful for healthcare, finance and other areas with rules like GDPR).
The framework lets you label data that needs to be removed before it is used, before it reaches your system for analysis.

Diagnostics

The goal is to let the platform automatically know if your service is alive, ready to receive traffic, and reporting useful diagnostic data.
This is standard but well‑implemented pattern for service health checking in a containerized environment (like Kubernetes).

Contextual options

It extends the standard .NET IOptions model to support runtime-contextual configuration. This means that the same option can resolve to different values depending on context (user, tenant, request metadata). Perfect example is A/B tests or feature flags.

ASP.NET Core extensions

A collection of middlewares and extensions for high-performance services - HTTP route enrichment for telemetry, the request latency middleware that powers the latency context system, and more.

Static analysis

A curated set of Roslyn analyzer configurations, shipped as a NuGet package.
Add it to your project and get a consistent code quality baseline across your team or organization, without everyone having to maintain their own .editorconfig rules.

Testing

A couple of utilities that solve 2 issues:

• FakeLogger / FakeLoggerProvider is an ILogger implementation that is easy to test and allows you to make deterministic assertions on what was logged (log level, message, structured properties).
• FakeTimeProvider is used for controllable TimeProvider.

Should you be using this?

My honest answer is: yes...but some of them.

If you're building any kind of .NET service that talks to external dependencies, Microsoft.Extensions.Http.Resilience is a near-automatic add.
The effort to wire it up is minimal.
The failure modes it prevents are the ones that wake people up at night.

If you're adding AI capabilities to a .NET application, Microsoft.Extensions.AI is worth adopting early. The abstraction layer is low-cost and already supported by the major providers.

If you've ever wasted time trying to assert on logged output in a unit test, FakeLogger is a one-line fix.

My two cents

The resilience telemetry enrichment integrates with the telemetry system. The AI middleware pipeline integrates with OpenTelemetry. The latency context flows through ASP.NET Core middleware. The testing utilities work cleanly with the logging and time abstractions.

It's a coherent ecosystem, not a random collection of utilities. That matters when you're maintaining a service at scale, because the alternative is assembling your own coherent ecosystem from parts.

Summary

Microsoft uses the dotnet/extensions library internally for its own services provision.
Developers do not have to build common patterns from scratch. There are many ready- to-use NuGet packages that deal with AI integration, resilience, telemetry, compliance, and testing. All of these packages are composable and proven at scale.

Review repository at this link: https://github.com/dotnet/extensions