# The .NET client with a broker-side test suite and a disputed framework floor

> RabbitMQ.Client is the RabbitMQ team's AMQP client for .NET Standard and .NET Framework, shipped on NuGet and tested against real broker containers. Its test targets reveal far more about the library than its README does, and the repository description and the README disagree about which framework version is the minimum.

**rabbitmq/rabbitmq-dotnet-client** — RabbitMQ .NET client for .NET Standard 2.0+ and .NET 4.6.2+

- Repository: https://github.com/rabbitmq/rabbitmq-dotnet-client
- Website: https://www.rabbitmq.com/dotnet.html
- Stars: 2,287 · Forks: 622
- Language: C#
- License: NOASSERTION
- Published: 2026-10-14 · Updated: 2026-10-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/rabbitmq-rabbitmq-dotnet-client

## A protocol client for a broker you already run

The repository description is blunt about scope: a RabbitMQ .NET client for .NET Standard 2.0+ and .NET 4.6.2+, written in C#. Everything else follows from that one line. This is a protocol client, not a broker, not a management console, and not a wrapper around an HTTP API. Your application owns the exchange, the queue and the connection; the library owns the AMQP framing, the channel state and the socket. Maintenance sits with the RabbitMQ team at Broadcom, and the homepage listed in the repository is the dotnet client page on rabbitmq.com, so the code you get from NuGet and the documentation you read live in two different places. Topic tags cover c-sharp, dotnet, dotnet-core and rabbitmq, which fixes the audience plainly: developers already running RabbitMQ who need to reach it from a .NET process.

## NuGet carries the library, the repository carries the harness

Because the library ships as a package, cloning the repository is optional for consumers. The README states the client is distributed via NuGet and points at the RabbitMQ.Client listing. What the repository itself holds is the machinery around that package: `RabbitMQDotNetClient.sln`, `Build.csproj`, `global.json` for pinning the SDK, `NuGet.config` for restore sources, and a `projects` directory. Next to those sit `docfx.json`, `toc.yml`, `APIDOCS.md` and a `_site` directory, so the API documentation is generated from this tree rather than curated on a separate site. Under `projects/Test`, the test code splits into `Unit`, `Integration` and `SequentialIntegration`. That split is the first real architectural signal in the repository: fast deterministic checks, broker-dependent checks and order-sensitive checks are treated as three separate costs, and the build targets are written to respect that.

## Building and the one test target that needs nothing

The README prints no install command for the package. It links the RabbitMQ.Client page on nuget.org and leaves installation to your package manager. For people who want to compile the library themselves, the repository root carries a Makefile whose build target is a single dotnet invocation against `Build.csproj`, and running that first is worthwhile because it produces what the three test projects consume.

```bash
dotnet build $(CURDIR)/Build.csproj
```

After the build, the unit target runs the fast suite with detailed console logging and nothing else attached: no broker container, no environment variables, no certificate directory. It is the only target a contributor can rely on on a laptop with Docker switched off.

```bash
dotnet test $(CURDIR)/projects/Test/Unit/Unit.csproj --logger 'console;verbosity=detailed'
```

The README also does not document a rollback path or a pinning scheme for the NuGet package, so if you need a fixed version, hold it in your own project file.

## The integration targets assume a container you did not start

Everything past the unit suite presumes a live broker. The Makefile sets `RABBITMQ_DOCKER_NAME` to `rabbitmq-dotnet-client-rabbitmq` and then shells out to `docker inspect` to resolve that container id, handing the result to `RABBITMQ_RABBITMQCTL_PATH` so the tests can drive rabbitmqctl against a running server.

```bash
RABBITMQ_DOCKER_NAME ?= rabbitmq-dotnet-client-rabbitmq
```

The integration target also sets `GITHUB_ACTIONS=true`, `RABBITMQ_LONG_RUNNING_TESTS=true`, `RABBITMQ_TOXIPROXY_TESTS=true`, `PASSWORD=grapefruit` and `SSL_CERTS_DIR` pointing at `.ci/certs`. Toxiproxy coverage means the suite injects network faults instead of only testing happy paths, and the certificate directory makes TLS part of the integration contract rather than an afterthought. Two costs follow. A contributor without a Docker daemon and a container of that exact name gets nothing from the integration or sequential targets. And `test-all`, which runs the whole `Build.csproj` matrix, carries an explicit comment that the expected OAuth2 environment must be set up first, so the complete suite is not reachable from a clean machine.

## Two minimum framework versions, and both major lines broke API

The metadata and the README disagree about the floor, and you will meet both. The repository description advertises .NET Standard 2.0+ and .NET 4.6.2+, while the README's supported platforms section says 7.x requires .NET framework 4.6.1 or any supported .NET version. Two hundredths of a framework version is a small gap, but it decides whether a locked-down build server still restores the package. The README splits support history into three bands: 7.x and 6.x both claim .NET framework 4.6.1 or a supported .NET version, while 4.x and 5.x drop to .NET 4.5.1 or later, with .NET Core 2.0 as the floor for the 5.x series. Verify the target framework your build pins before you commit to a major version. The upgrade cost lands on the API surface, not the package reference: both 7.x and 6.x are marked as introducing potentially breaking public API changes, with 7.x pointing at a dedicated `v7-MIGRATION.md` beside `CHANGELOG.md`. Code written against pre-7 connection and channel types needs reading before an upgrade, not just a version bump. The package is double-licensed under the Mozilla Public License 2.0 and the Apache License version 2, so either one is your choice, and the last push was on 2026-09-24.

## Docs are built in-tree, and reconnection behaviour is not documented here

`docfx.json`, `toc.yml`, `APIDOCS.md` and the checked-in `_site` directory sit at the top level, so the API pages under rabbitmq.github.io are produced from this repository. Tutorials and the documentation guide point at rabbitmq.com instead, which means one behaviour question can land you in two different places depending on which link you follow. What the top-level files do not carry is a stated default for reconnection policy, for consumer retry or for logging configuration, and neither does the README. If those three matter to your design, the generated API pages and the tutorials site are the only places left to check, and you should read `v7-MIGRATION.md` before assuming a pre-7 example still compiles.

## Two situations where this library is the wrong choice

First, administration. If you need to create vhosts, inspect queues, rotate credentials or monitor nodes, this repository has no CLI, no admin API wrapper and no dashboard. rabbitmqctl appears exactly once, as a path handed to the test harness. Second, comparative evaluation. The README names no alternative .NET client and offers no feature matrix, so a decision made from this repository alone rests on the vendor relationship and on the migration guide. That is the trade the project makes explicitly: instead of mocking broker behaviour, the integration suite drives rabbitmqctl against a real container, so the library is tested against the broker it ships with. Price that against the breaking API changes between 6.x and 7.x before a team commits to it.

## Conclusion

Adopt RabbitMQ.Client when your .NET service already talks to RabbitMQ and you want the broker's own team maintaining the protocol layer, and pin an exact package version because both 6.x and 7.x broke public API. Do not pick it as a management tool, it has none. Before you ship, check the target framework floor against your build server, since the README and the repository description disagree, and run the unit target before the integration target, which needs a Docker container named rabbitmq-dotnet-client-rabbitmq.

## FAQ

### How do I add the RabbitMQ .NET client to a .NET project?

It is distributed on NuGet as the RabbitMQ.Client package, and the README links that package page rather than printing an install command, so use your own package manager to add it. The repository itself is only needed if you intend to build from source.

### Which .NET versions does the RabbitMQ .NET client 7.x line support?

The README says 7.x requires .NET framework 4.6.1 or any supported .NET version, while the repository description says .NET Standard 2.0+ and .NET 4.6.2+. Older 4.x and 5.x lines require .NET 4.5.1 or later, with .NET Core 2.0 as the 5.x floor.

### How do I run the integration tests for the RabbitMQ .NET client?

The Makefile test target runs the integration project with rabbitmqctl pointed at a Docker container named rabbitmq-dotnet-client-rabbitmq by default, plus PASSWORD=grapefruit and a certificate directory at .ci/certs. The test-all target needs the OAuth2 environment set up in advance, according to the note in the Makefile.

### Can I use the RabbitMQ .NET client in a commercial product?

Yes. The README describes the library as double-licensed under the Mozilla Public License 2.0 and the Apache License version 2, and gives the Apache Public License 2.0 as the option to pick when including the client in a commercial product.

## Sources

- [Issues](https://github.com/rabbitmq/rabbitmq-dotnet-client/issues)
- [Project website](https://www.rabbitmq.com/dotnet.html)
- [rabbitmq/rabbitmq-dotnet-client on GitHub](https://github.com/rabbitmq/rabbitmq-dotnet-client)
- [README](https://github.com/rabbitmq/rabbitmq-dotnet-client/blob/main/README.md)
- [Releases](https://github.com/rabbitmq/rabbitmq-dotnet-client/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rabbitmq-rabbitmq-dotnet-client