StackExchange.Redis: the .NET client that treats RESP as a contract, not a server list

The compatibility claim is a protocol claim, and it is deliberately unfalsifiable

The most substantive paragraph in the README is the one about which servers work. StackExchange.Redis is described as a .NET client for communicating with RESP servers such as Redis, Azure Managed Redis, Garnet, Valkey and AWS ElastiCache, and a wide range of other Redis-like servers. Then comes the qualifier that shapes how you should read everything else: the project does not maintain a list of compatible servers, and if the server has a Redis-like API it will probably work fine. That is a deliberate refusal to publish a matrix, and it cuts both ways. In your favour, a new server that implements RESP does not need to be blessed by this project before you can try it. Against you, there is no table to check when a vendor product behaves differently, so you find out by logging an issue with details. The practical consequence is that the client defines itself by the protocol rather than by a product list, and evaluating a target server is an integration question rather than a lookup.

Release notes live in two places, split at version 3.0

Version discovery is split along a line the README makes explicit: release notes for 3.0 onwards are on GitHub Releases, and earlier releases are documented at seredis.dev/ReleaseNotes. The recent tags show the split in practice. Several lines ship in parallel: 4.0.155-alpha on 2026-10-31, and 2.13.23 and 3.4.31 both on 2026-11-02. Neither place is a substitute for the other: the GitHub releases carry the recent history, and the docs site holds the older record.

Directory.Packages.props means one file governs every dependency version

The repository layout describes a Central Package Management style build, and the file names at the root are the evidence. There is `Directory.Build.props` and a matching `Directory.Build.targets` for shared MSBuild properties, plus `Directory.Packages.props` sitting alongside them, which is where package versions get pinned centrally rather than in each project's own project file. Two more root files complete the picture: `global.json`, which pins the .NET SDK the build expects, and `version.json`, which carries version data. The solution file itself is `StackExchange.Redis.slnx`, the newer XML solution format, and it sits next to `StackExchange.Redis.sln.old` and `StackExchange.Redis.sln.DotSettings`. If you are contributing, the practical consequence is that you do not bump a package version in a random csproj: you change it in `Directory.Packages.props`, which means dependency review for this project happens in exactly one diff. `Build.csproj` is the build driver, and `Shared.ruleset` holds the analysis rules.

A signing key and two automation entry points sit at the root

Two root entries tell you this is a repository that ships signed binaries from a build pipeline rather than something built ad hoc. The first is `StackExchange.Redis.snk`, a strong name key file kept in the repository, which is what allows the produced assembly to be strong named. The second pair is `build.cmd` and `build.ps1`, the Windows entry points that wrap the actual build, which in turn is described by `eng/` in the tree, the engineering scripts directory. There is also a `NuGet.Config` at the root, so the restore sources for this project are declared in the repository rather than inherited from whatever machine you happen to clone onto, and a `.devcontainer/` alongside `AGENTS.md`, `CLAUDE.md` and `CONTRIBUTING.md` tells you the project expects a specific containerised environment and has written instructions aimed at coding agents. `SECURITY.md` is present as its own file, separate from `CONTRIBUTING.md`, so vulnerability reports have a defined path. None of that appears in the README, and all of it is what you would want before your first pull request.

The README is a compatibility statement and a link, nothing more

It is worth being blunt about the size of this file, because it shapes what an evaluation can conclude. After the compatibility paragraph, the entire body is a pointer to seredis.dev for all documentation, a build status badge, a package status table pointing at NuGet for the stable and pre-release channels of the StackExchange.Redis package, and the two release note locations. There is no code sample, no configuration example, no connection string format, and no list of types. The package status table is the only operational detail, and it exists to distinguish the stable channel from the absoluteLatest pre-release channel on NuGet. So if you are searching the README for how to construct a multiplexer, set up a connection, or handle a failure, none of it is there. Everything of that kind is at seredis.dev, and that split between a very short README and a separate documentation site is the shape this project has chosen.

Development directories separate infrastructure work from the library itself

Three top level directories tell you how work in this repository is organised. `src/` holds the library, and `tests/` holds its test project, which is the arrangement you would expect. The third is `toys/`, a name that signals sample or experimental code kept alongside the product rather than inside it. Alongside those sits `docs/`, `assets/` and `build/`. The presence of `toys/` is the informative part: it tells you the project keeps scratch programs in the repository instead of in a personal sandbox, which makes them easy to look at but also means the repository carries code that is not the shipped library. That matters when you are assessing what you are depending on. If you only want the client, `src/` plus the NuGet package is the whole of it, and none of the surrounding tooling in `eng/`, `build/`, `toys/` or `assets/` ends up in your build.

Licensing is left to the LICENSE file, with no summary in the README

There is a `LICENSE` file at the repository root and nothing else on the subject in the README, which is a deliberate-looking gap rather than an oversight you should paper over. The repository metadata lists the licence as MIT, but no licence paragraph appears in the README body. For a library that most teams take as a transitive dependency rather than choosing deliberately, this is the point to check before you build anything on top of it, and to check again if the terms in that file change between versions, because a client library's licence is what your distribution inherits. The same pattern runs through the rest of the repository: the README states facts about servers and releases, the docs site states facts about the API, and `SECURITY.md`, `CONTRIBUTING.md` and `LICENSE` state facts about process and terms. Nothing is duplicated between them, which is tidy, and it also means no single file tells you everything you need before you commit to the dependency.

Editorial conclusion

Choose StackExchange.Redis when your .NET application needs to talk to a Redis-like server and you want one client that follows the RESP protocol instead of one written per vendor. Skip it if you need the README to tell you how the API works, because the file is a compatibility statement and a link, and everything else lives at seredis.dev. Before you commit, check the release notes on GitHub for the 3.x line and on seredis.dev for anything older than 3.0, since the project splits them deliberately, and read the LICENSE file at the repository root rather than assuming terms from the package page. Versions 2.13.23 and 3.4.31 were published on 2026-11-02, and the last push to the repository was on 2026-11-01.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. StackExchange/StackExchange.Redis on GitHub