To whet your appetite as a Rebus user, who is eager to one-up your game, I have posted a bunch of screenshots here on the Fleet Manager page.
While Fleet Manager is still in development and is nowhere near finished yet, it can still be quite useful to provide an overview over what is running and what is not.
If you are interested in getting access, please go consider the Rebus Pro offering β it includes a 24h support agreement in addition to instant cloud-hosted Fleet Manager access.
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.
.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).
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.
In case you are using Microsoft SQL Server, you may have tried writing a MERGE (...) statement…. did you think it was fun? π
I think MERGE statements are not fun at all, but from time to time it IS necessary to execute a performant UPSERT-type of operation.
Maybe you also know that the fastest way to execute a huge number of upserts is to
create a custom table data type
create a stored procedure that executes the MERGE statement, using the data type as its input type
STREAM rows to the stored procedure via a table in tempdb
which can be pretty tedious to code.
Which is why the “upsert helper”, Debaser, was made π
With Debaser, you can execute obscenely fast upserts by doing the following things:
Create a class that matches the layout of the table you want
E.g. something like
class SomeDataRow
{
public SomeDataRow(int id, decimal number, string text)
{
Id = id;
Number = number;
Text = text;
}
public int Id { get; }
public decimal Number { get; }
public string Text { get; }
}
will do.
Initialize the upsert helper
This can be done like this:
var helper = new UpsertHelper<SomeDataRow>(connectionString);
and then you might want to
helper.CreateSchema();
when your application starts up. This will create a table, a custom table data type, and an appropriate stored procedure.
Upsert like crazy
Pass very very long sequences of row objects to the upsert helper like this:
await helper.Upsert(longLongSequence);
which is cool, because the upsert helper streams the data to SQL Server.
Pretty cool
If you think this looks cool, you should go to the Debaser wiki and read more about it, and maybe you want to Install-Package Debaser and start punishing your database right away?
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.
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.
This website uses cookies to collect statistics about how many visitors come by. That's the only reason we're using cookies! We're guessing you're ok with this, but you can opt-out if you wish.AcceptRejectRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.