RabbitMQ 3.5.0 is around the corner now and
I'd like to announce a few backwards-incompatible changes in RabbitMQ .NET client 3.5.0.
## Custom Delegates Replaced with Standard Generic Types
In 3.4.x, and for most of the history of the client, various events were using
delegate/handler types that had virtually identical signatures:
The only thing that was different was event arguments type. This solution made sense in 2007
when the client was first created but not in 2015. In 3.5.0, we've replaced those types with
EventHandler<T>, e.g. EventHandler<ConnectionBlockedEventArgs>.
In a few places handlers were replaced with Action<T>, Action<T1, T2>, Func<T1, T2>,
and so on.
## Concurrent Consumer Operation Dispatch
Previously the client dispatched all incoming protocol methods (e.g. basic.deliver
or basic.cancel or basic.consume-ok) on the I/O thread. Not only this isn't
particularly efficient on modern multi-core systems, this had profound limitations
on what IModel methods were safe to use from consumer event handlers.
In 3.5.0, consumer operations are dispatched concurrently. The client will preserve the order
in which methods are dispatched on individual channels. Connection-wide, the ordering is not
It is possible to provide a custom TaskScheduler to control degree of concurrency (e.g. go back
to the single-threaded dispatch implementation from earlier versions) and integrate better
with your consumer code that may already use TPL with custom scheduler(s).
## Heavier Use of Properties
Many classes in the client used to use properties intermixed with "regular" methods that imitated
get-only properties. Most of such sites now use auto-implemented properties.
## Minimum Required .NET Version
The client now requires .NET 4.0.
## Minimum Required Visual Studio Version
For those looking to contribute or read the code, the client now requires Visual
Studio 2013 (Community Edition works great) or later.
## What to Expect in 3.6.0
RabbitMQ engineers care about backwards compatibility but .NET client badly needed
modernisation. Now that we have mostly caught up with .NET 4.0, we can explore
how the features it provides (e.g. the TPL) can be integrated into the client's API.
In addition, our users ask for features such as Windows RT support. 
This may mean more breaking changes. We'll try to keep things compatible but making
it easier (or possible) to use the client in the modern .NET ecosystem is an even
After the 3.5.0 release, RabbitMQ development takes one more step to being
entirely done on Github: we switch to GitHub issues and use pull requests as our
primary way of submitting changes.
This means it is easier than ever for you to participate, report bugs, ask for
features you'd like to see and contribute code.
The repository is at https://github.com/rabbitmq/rabbitmq-dotnet-client
Staff Software Engineer, Pivotal/RabbitMQ