# StackExchange.Redis.Extensions: a .NET wrapper that makes the serializer and pool your decision > The library sits on top of StackExchange.Redis and turns objects, locks, streams and geo queries into a typed API, but it reaches into a lot of Redis surface while documenting only a slice of it in detail. **imperugo/StackExchange.Redis.Extensions** — StackExchange.Redis.Extensions is a library that extends StackExchange.Redis, making it easier to work with Redis in .NET applications - Repository: https://github.com/imperugo/StackExchange.Redis.Extensions - Stars: 629 · Forks: 178 - Language: C# - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/imperugo-stackexchange-redis-extensions ## What the wrapper actually adds to the raw client StackExchange.Redis is a low level client. It exposes commands, returns byte arrays, and leaves serialization to the caller. StackExchange.Redis.Extensions exists to move that work upward. The project description calls it a library that extends StackExchange.Redis and makes it easier to work with Redis in .NET applications, wrapping the base library with serialization, connection pooling and higher level APIs so complex objects can be stored and retrieved without boilerplate. The change in practice is visible in the method names. Instead of writing and reading byte payloads yourself, you call something like GetAsync with a type argument and the library handles the round trip through a serializer you chose at registration time. The same convenience applies to keys, hashes, sets, sorted sets and counters, all reached through a database abstraction rather than a raw multiplexer. The scope is broad. The feature list covers pub and sub with typed handlers, Redis Streams with consumer group support, geospatial indexes, HyperLogLog, bitmap operations, Lua scripting, key tagging and search, key management commands, and transparent compression with GZip, Brotli, LZ4, Snappy and Zstandard. It also includes an ASP.NET Core health check for connection pool monitoring, Azure Managed Identity support, OpenTelemetry integration and .NET 8 keyed services for multiple named Redis instances. The target frameworks are .NET Standard 2.1, .NET 8, .NET 9 and .NET 10. ## Serialization is a package choice made at install time The most consequential decision in this library is not made in code but in the package list. There is no single serializer to enable. The project splits serializers into separate NuGet packages, and the quick start shows you adding the core package, one serializer package and the ASP.NET Core package. Six serializers are published side by side. System.Text.Json is described as recommended for most scenarios, Newtonsoft is there for JSON.NET compatibility with existing code, and the binary formats include MemoryPack, which targets net7.0 and up, MsgPack, Protobuf and Utf8Json. The core and ASP.NET Core packages hold the abstractions and implementations, while the serializer packages supply the format. Compression is layered on top of whatever you picked. The architecture diagram shows a serializer resolving to an optional compressed serializer, which in turn wraps System.Text.Json, Newtonsoft or one of the other formats. That means the wire payload is compressed first and then encoded, and the compressors ship as their own optional packages, with LZ4 listed as the lowest latency option. One practical consequence follows from that split. Changing the stored format later is not a configuration toggle, because the format is fixed by the package you installed and the serializer you registered. A cache written with MemoryPack and read with System.Text.Json will not deserialize, so treat the serializer choice as part of your data format rather than a performance preference you can flip freely. ## Connection pooling with LeastLoaded and RoundRobin The library manages its own connections rather than handing you a multiplexer to use directly. The architecture diagram shows the database abstraction reaching a connection pool manager, which in turn holds a set of connections against the Redis server. Two strategies are named in the feature list: LeastLoaded and RoundRobin. The configuration section in appsettings.json shows the knobs that shape the pool. PoolSize is set to 5 in the example, alongside ConnectTimeout and SyncTimeout of 5000 milliseconds, a Database index of 0, and a Hosts array where each entry carries a Host and a Port. The example points at localhost on port 6379 with Ssl false and Password empty, and marks the instance IsDefault true. AllowAdmin is also present in the sample, which matters because administrative commands need that switch. Multiple named instances are supported through the same configuration shape, and the feature list mentions .NET 8 keyed services and FromKeyedServices attributes, so a single application can talk to more than one Redis deployment with different serializers or settings. The ASP.NET Core package adds a health check that reports on the connection pool, which is the piece most worth enabling in production since pool exhaustion shows up as latency long before it shows up as an exception. ## Adding the packages and registering the client The quick start in the README is a four step tutorial, and the first three steps are enough to have a working client in a service. Install the packages first. ```bash dotnet add package StackExchange.Redis.Extensions.Core dotnet add package StackExchange.Redis.Extensions.System.Text.Json dotnet add package StackExchange.Redis.Extensions.AspNetCore ``` The serializer package is where you pick a format, and the ASP.NET Core package is what provides the dependency injection registration and middleware. Next, the configuration block is read from the standard configuration file. ```json { "Redis": { "Password": "", "AllowAdmin": true, "Ssl": false, "ConnectTimeout": 5000, "SyncTimeout": 5000, "Database": 0, "Hosts": [ { "Host": "localhost", "Port": 6379 } ], "PoolSize": 5, "IsDefault": true } } ``` The Hosts array is where multiple endpoints would be listed, and IsDefault marks which one answers for the default registration. Finally, the section is bound to a configuration type and passed to the extension method that registers the client, with the serializer passed as a type argument. ```csharp var redisConfig = builder.Configuration.GetSection("Redis").Get(); builder.Services.AddStackExchangeRedisExtensions(redisConfig); ``` The generic argument is the whole point of the package split. Swap SystemTextJsonSerializer for another serializer type and every stored value follows the new format, provided nothing has to read the old one. ## Storing objects, expiries and bulk writes through IRedisDatabase Once registered, the application injects a database abstraction and works with typed values. The README example defines a service that takes IRedisDatabase in its constructor and shows the main call patterns a new user will need. ```csharp public class MyService(IRedisDatabase redis) { public async Task Example() { // Store an object await redis.AddAsync("user:1", new User { Name = "Ugo", Age = 38 }); // Retrieve it var user = await redis.GetAsync("user:1"); // Store with expiry await redis.AddAsync("session:abc", sessionData, TimeSpan.FromMinutes(30)); // Bulk operations var items = new[] { Tuple.Create("key1", "value1"), Tuple.Create("key2", "value2"), }; await redis.AddAllAsync(items, TimeSpan.FromHours(1)); // Search keys var keys = await redis.SearchKeysAsync("user:*"); } } ``` The overload taking a TimeSpan writes a key with a server side expiry, which is how a session entry is normally handled here. AddAllAsync applies a single expiry across a batch of tuples, which is the right call for a group of entries that share a lifetime. SearchKeysAsync takes a pattern, and the key search capability is also listed as a feature, so key discovery is a first class operation in this library rather than something you assemble yourself. The wider surface follows the same pattern: hash operations with per field expiry require Redis 7.4 or later, distributed locks release automatically when the returned object is disposed, and set operations expose union, intersect and diff as a set combine capability. ## A feature list that runs ahead of the documentation This is where a careful reader should slow down. The feature list is long and confident, but the detail behind it is thin. Lua scripting for atomic server side operations is one bullet. GeoSpatial indexes, with commands such as GEOADD, GEOSEARCH and GEODIST, is another. Bitmap operations for analytics and feature flags, transparent compression across five algorithms, Azure Managed Identity support, OpenTelemetry integration and the IDistributedCache adapter with a Microsoft compatible Hash schema are all listed as well. For most of these, the README gives a name and nothing else. There is no sample for a Lua script, no configuration key for Managed Identity, no guide for registering the OpenTelemetry instrumentation, and no walkthrough for the IDistributedCache adapter. The documented surface, the four step quick start and the package tables, is genuinely useful, but it is a fraction of the advertised surface. That gap creates a specific risk. A team can reasonably conclude from the list that a feature exists, adopt the package, and then find that the actual method names, overloads and options are not spelled out anywhere in the visible documentation. The repository does carry a doc directory, an llms.txt file and a Claude Code plugin with configure, scaffold and diagnose commands, and the project ships a sample MVC application, so the details exist somewhere, but the README itself does not print them. Version numbers are not printed either. The samples show a Version of 1.0.0 in package.json, which describes the repository tooling package rather than the published NuGet versions, so it tells you nothing about which library release you would install. Recent releases carry semantic version numbers, with the newest listed as v13.0.1 and the release before it as v13.0.0, so the library is versioned independently of the tooling package. ## What the wrapper costs you against the raw client The alternative is to use StackExchange.Redis directly, and for some workloads that is the better call. The raw client gives you a multiplexer and a connection configuration, and you can issue any command the server supports, including commands released after the wrapper was last updated. With the wrapper you are limited to the operations the library has implemented, and since the documentation only demonstrates a fraction of its own feature list, discovering the rest means reading code. The wrapper wins on the boring work. Serialization, compression, connection pool sizing, expiry handling, typed pub and sub handlers, consumer groups and lock release on dispose are all things you would otherwise write and test yourself. Registration is a single extension method, and the health check gives you a probe for the pool. Azure Managed Identity support removes a class of credential handling code that is otherwise easy to get wrong. The wrapper loses when you need the wire. If you are debugging latency, tuning socket options, or relying on a Redis command the library has not wrapped, the abstraction is in the way. The IDistributedCache adapter is worth a look for a specific reason: it lets an application that already depends on the Microsoft caching interface use this library without changing call sites, but it also means the cache schema is fixed to the Hash layout, so Redis specific data structures such as sorted sets or streams are unavailable through that path. A middle position also exists. Use the wrapper for the object caching your application does everywhere, and keep the raw client injected alongside it for the handful of operations that need direct control. The project exposes the underlying client types, so both can coexist in one container. ## Maintenance pace, upgrade cost and the MIT licence The project is not archived, and the last push was on 2026-08-07, so the code base was receiving changes within the last few months of the current cycle. Recent releases show v12.6.0 on 2026-07-09, then v13.0.0 and v13.0.1 on the same day, 2026-08-03, with the newest described as memory and CPU optimizations and the one before it as API enrichment. A major version bump that changes the public API is the main upgrade cost here, since the project says v13.0.0 was an API enrichment release, and code written against v12 will need review when you move up. The repository itself is a full solution with a src directory, a tests directory, a samples directory, continuous integration and CodeQL workflows, a CODE_OF_CONDUCT file, a SECURITY file and a contribution guide. The README badge claims more than 1600 passing tests, which is a statement by the project rather than an independent measurement. The licence is MIT, so the code can be used, modified and redistributed inside commercial products without a per-seat fee, provided the licence text and copyright notice travel with it. That is a permissive grant and it carries no obligations around support, so the operational risk of depending on this library sits with your team rather than with a vendor contract. The repository also publishes an llms.txt file and a Claude Code plugin, and a package.json with husky hooks configured for dotnet format. The plugin is aimed at assistants rather than at runtime use, so it does not affect how the library behaves in your application. ## Conclusion Teams that want typed object storage, a pluggable serializer and DI wiring without hand writing Redis calls should adopt it, while teams that need predictable low level control over every round trip, or that need Redis features the documentation never covers, are better served by the raw StackExchange.Redis client. Before adopting, check that the exact commands you depend on are documented rather than merely listed, that your target framework is covered by the packages you install, and that the serializer package you pick matches the data you already have stored. ## FAQ ### Which serializer should I choose for StackExchange.Redis.Extensions? The library publishes one NuGet package per serializer rather than a single switch, and the package table marks System.Text.Json as recommended for most scenarios with Newtonsoft offered for JSON.NET compatibility. Binary options include MemoryPack for net7.0 and above, MsgPack, Protobuf and Utf8Json, and the format is fixed by the package you install and the serializer you register. ### Can I use StackExchange.Redis.Extensions with the ASP.NET Core IDistributedCache interface? Yes. The feature list includes an IDistributedCache adapter that uses the Microsoft compatible Hash schema, and a separate AspNetCore package provides the dependency injection integration and middleware. Because the adapter is backed by Hash, Redis specific structures such as sorted sets and streams are not reachable through that path. ### How does StackExchange.Redis.Extensions handle distributed locks and connection pool health? The feature list describes distributed locking with IAsyncDisposable auto-release, so a lock is released when the handle is disposed. The AspNetCore package also adds a health check that monitors the connection pool, which is the piece to enable first in a deployment. ### Which .NET versions does StackExchange.Redis.Extensions target? The stated targets are .NET Standard 2.1, .NET 8, .NET 9 and .NET 10. The .NET 8 keyed services feature and the FromKeyedServices attribute for multiple named Redis instances are noted as depending on .NET 8 or later. ## Sources - [imperugo/StackExchange.Redis.Extensions on GitHub](https://github.com/imperugo/StackExchange.Redis.Extensions) - [Issues](https://github.com/imperugo/StackExchange.Redis.Extensions/issues) - [License: MIT](https://github.com/imperugo/StackExchange.Redis.Extensions/blob/master/LICENSE) - [README](https://github.com/imperugo/StackExchange.Redis.Extensions/blob/master/README.md) - [Releases](https://github.com/imperugo/StackExchange.Redis.Extensions/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/imperugo-stackexchange-redis-extensions