Category Archive Rebus

If you’re interested in receiving weekly emails with little nuggets of Rebus wisdom, go here and sign up! 💌

Lots of small changes, only a few of them breaking(*), nothing earth-shattering 🙂

The biggest change is probably that the test helpers (FakeBus, SagaFixture, etc.) were moved to a separate repository and its own NuGet package: Rebus.TestHelpers.

Another slightly bigger change is that Rebus now targets .NET 4.5, .NET 4.6, and .NET Standard 2.0. If anyone is missing the .NET Standard 1.3. support, please ✉️➡️[email protected] and let us know why 👻

Some of the smaller changes include a few performance improvements 💨, an extension point to customize how topic names are created out of .NET types, the ability to “fail fast” (i.e. skip retries) in various situations 💥, and a way to delay message processing when starting up the bus.

As usual, WIRE-COMPATIBILITY is 100% with all versions of Rebus from 2 and up, so you don’t need to go all-in to start upgrading your endpoints! 😇

See the full 5.0.0 changelog entry for more details on what was changed.

—
(*) In theory, all changes can be breaking… in this case, the version was bumped to 5 primarily because the IRoutingApi interface was extended with the Defer method signature, and because all of the testing helpers were moved.

If you’re running your Rebus stuff on .NET Core, and you’re using “Microsoft Extensions Logging” (that’s just not a bite-sized title for a logging library), you’re in luck: Rebus now has Rebus.Microsoft.Extensions.Logging, so you can

var loggerFactory = new LoggerFactory()
	.AddYourSinksHere();

Configure.With(...)
	.Logging(l => l.MicrosoftExtensionsLogging(loggerFactory))
	.Transport(t => t.Use(...))
	.(...)
	.Start();

and have Rebus log its stuff there, too.

The package is currently in alpha, but since there’s not much to it, we expect it to be pretty stable.

Happy logging! 🤠

It only took 23 beta versions to get there 🙂

The cool thing about Rebus 4 is that it targets both .NET 4.5 and .NET Standard 1.3, making it possible to run Rebus endpoints on all server platforms that matter. In fact, I know of people who at this point have been running quite a lot of Rebus on AWS… On Linux! In Docker containers!

Most integration packages have been updated too, and almost all of them are supported on .NET Core as well, so you should go ahead and try it out.

Notable exceptions at this moment are Rebus.Msmq and Rebus.AzureServiceBus

MSMQ is not supported by any .NET Standard version, so it’s quite obvious why the 4.0.0 version of that package still only targets .NET 4.5.

Azure Service Bus is supported on .NET Core now though, but it has been implemented in a completely new version of the driver that has a radically changed API and therefore requires a lot of work to update. Version 4.0.0 of Rebus.AzureServiceBus will therefore target .NET 4.5 only.

You may go Update-Packages Rebus now 🙂

.NET Core is Microsoft’s new incarnation of .NET, where many things have been changed to be able to accommodate future needs for (primarily server side) application development. This is also the biggest change ever in the .NET world that is not backwards compatible!

For a long time we have had the ability to take an old .NET 2.0 DLL and plop it down next to our other DLLs, and then we would be able to use it right away. Because .NET Core is such a huge change (i.e. it uses a radically re-engineered runtime), that is no longer possible.

This puts a big burden on library developers (e.g. like me 🙂 ) who want to be prepared for the future, while supporting all of the old stuff still.

The good news is that with Visual Studio 2017 and the new CSPROJ format, it has actually become pretty straightforward to write libraries that target multiple frameworks by leveraging the <TargetFrameworks> element in the CSPROJ file (note the plural ‘s’ in there – when you create a new project, there is a <TargetFramework> element, but you need to add an ‘s’ if you put several targets in there).

By the power of open source and a persevering Rebus contributor, beta versions of Rebus 4 have now been released, targeting .NET 4.5 as always as well as .NETStandard 1.6 (which is .NET Core 1.0)

I am now in the process of porting all of the 40+ Rebus projects that it makes sense to port. You can follow the progress here. If you feel like messing a bit with .NET Core and becoming a Rebus contributor, feel free to get in touch and then we’ll figure out how you can help.

Exciting times ahead! 🙂

Happy New Year!

This is just to let you know that Rebus 3 is out 🙂

The version was bumped to 3 because IAdvancedApi and IDataBus have been extended with more methods, and there are some changes around how to manually create transactions when sending messages outside of message handlers.

It is absolutely 100% wire-compatible with Rebus 2!

If you are interested in checking out which features were added, you can go to the tag comment and see the relevant bullets from the changelog. Most notable hightlights are a synchronous bus API (which can be accessed via bus.Advanced.SyncBus) and a few extra much needed methods on IDataBus.

Changes you need to make if you upgrade

If you are using DefaultTransactionContext

If you do this in your application:

using(var context = new DefaultTransactionContext())
{
    AmbientTransactionContext.Current = context;

    try
    {
        await bus.Publish(anEvent);

        await context.Complete();
    }
    finally
    {
        AmbientTransactionContext.Current = null
    }
}

you will have to change it to something like this:

using(var scope = new DefaultTransactionContextScope())
{
    await bus.Publish(anEvent);

    await scope.Complete();
}

which is much prettier and much much harder to mess up 🙂

If you implemented IDataBus or IAdvancedApi…

…you will have to add two extra methods on IDataBus: Task<Stream> OpenRead(string dataBusAttachmentId); and Task<Dictionary<string, string>> GetMetadata(string dataBusAttachmentId); and one extra property on IAdvancedApi: ISyncBus SyncBus { get; }

If you implemented IDataBus or IAdvancedApi you most likely did it in order to decorate either service or to function as a test stub. Hopefully it will not be too cumbersome to extend those implementations to support the extra operations.

If you are using Rebus’ built-in logging

If you are using the GetCurrentClassLogger() method of IRebusLoggerFactory you will have to call GetLogger<YourClass>() instead – the stack frame walking turned out to be unreliable in some method inlining scenarios.

If you are using other Rebus packages

You will most likely have to update them to a version that is compiled against 3.0.0.

I am happy to announce that Rebus 2 has finally been published with a “real version number”.

After many year of notorious unwillingness to bump the version to something binding (i.e. >= 1.0), Rebus is now out in version 2.0.1, accompanied by its > 30 integration packages.

This means that all APIs are now stable, and users can rely on pulling down only non-breaking changes when they update packages within the v2 range.

Happy messaging! 🙂

Rebus 2 has been in development for about 1,5 years now, and it has been used in production for at least one year by myself and many others… and by “Rebus 2”, I mean Rebus versions >= 0.90.0 🙂

Sorry about the confusion

First off, I would like to apologize for the confusion about the versions. For historical reasons the versions less than and including 0.84.0 are known as “Rebus 1”, and versions greater than and including 0.90.0 are known as “Rebus 2”. If you are interested, you can see the original announcement in this blog post.

Fixing the versioning

In order to “fix the versioning”, Rebus will soon become a real version 2.0.0.

In semantic versioning this marks as big step, as versions < 1.0.0 are allowed to make breaking changes for every single release, and thus are inherently unstable. Therefore, when Rebus becomes 2.0.0, it means that patch increments are for bugfixes and small improvements, minor increments are for backwards compatible feature additions, and then the major version number is incremented whenever a change is made which is NOT readily compatible with existing code.

When is this going to happen?

A few things need to be done before this is going to happen, where the main thing is that the ground must be laid for how the Rebus code repository should be split into separate repositories in the future.

It does not mean that 2.0.0 will necessarily wait for all of the libraries to have been moved, it just means that a few libraries must have been moved to prove that the code structure and everything surrounding the code works to support the new way.

If you are interested, you can follow the progress here on GitHub – for now, the due date for the milestone is set to the October 1, 2016.

Summary

If all goes well, Rebus 2.0.0 will be published on October 1, 2016 🙂

The most recent addition to Rebus is a “data bus”, i.e. an implementation of the claim check pattern as described in The Good Book.

With the data bus, it has suddenly become extremely easy to transfer e.g. large CSV files from one endpoint to another, because the bus now supports creating attachments from streams, as well as opening up attachments as streams again in the receiving end.

Data bus attachments support including arbitrary metadata along with the attachment, allowing you to pass along file names, information about who made the attachment, etc.

You can read more about the feature on the official documentation wiki page.