ByMogens
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.
ByMogens
It took a couple of iterations to figure this out, but finally it has become clear which shape the commercial Rebus offering is going to take.
Say hello to REBUS PRO! 🙂
Rebus Pro is
accessible by subscription (monthly, with savings for 3 or 6 months commitment).
Please shoot an email to [email protected] if you are interested in hearing more 🙂
(*) Bring Your Own Hardware 😉
ByMogens
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 🙂
ByMogens
.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! 🙂
ByMogens
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
MERGE statement, using the data type as its input typewhich 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:
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.
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.
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.
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?
Happy upserting!
ByMogens
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.
DefaultTransactionContextIf 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 🙂
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 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.
You will most likely have to update them to a version that is compiled against 3.0.0.