Particular Software Blog

Latest articles

• The new and improved NServiceBus testing framework

  Written by Tim Bussmann on February 15, 2017

  

  Tests are the life blood of many large codebases. They protect you from introducing bugs and in some cases, are instrumental in your code's design. Because of this, maintaining those tests is every bit as crucial as the underlying code that it tests. Like the rest of the project, your tests should be clear, concise, and consistent with your code style. Otherwise, tests might fall into disrepair and end up in a large bucket called technical debt, never to be heard from again.

  Read more →

• RabbitMQ updates in NServiceBus 6

  Written by Brandon Ording on January 19, 2017

  The new RabbitMQ transport for NServiceBus 6 has one overriding theme: speed. Although we've added a few other features as well, the biggest news is how much faster we've made the new version of the RabbitMQ transport. We've redesigned the message pump to be more efficient, so it can handle more incoming messages. Outgoing messages are sent faster. We've even contributed changes to the official RabbitMQ Client project to increase its performance. Almost everything we've done was focused on making your systems faster and more efficient.

  Read more →

• Batch Dispatch #0

  Written by Particular Team on December 21, 2016

  Happy holidays to all of you readers out there! Lately, several of our staff members have been active in the community, sharing valuable insights into building distributed systems. We thought we'd take this opportunity to share some of those resources, as well as other fun stuff, with you. With a bit of async/await, Azure Service Bus, AngularJS, code-driven visualizations, and even a throwback to the Commodore 64, there's something in here for everyone. We hope you enjoy!

  Read more →

• NServiceBus on .NET Core - Why not?

  Written by David Boike on November 10, 2016

  .NET Core is out. Officially. After a lot of waiting, it's finally a real, finished, RTM thing, and as developers who are passionate about the .NET ecosystem, we're very excited about it. How cool is it to know that we can write code in C# (or VB.NET, or F#, etc.) and have it run on Windows, Linux, and even macOS? So why on earth doesn't NServiceBus support .NET Core yet? Well, good question.

  Read more →

• Async/await tips and tricks

  Written by David Boike on November 3, 2016

  Many .NET developers have been busy upgrading their code to take advantage of the async and await keywords. These keywords make asynchronous programming a lot easier by allowing us to represent a call to an asynchronous method almost as if it were a synchronous one. We just add the await keyword, and the compiler does the hard work of dividing the method into sections and keeping track of where to resume execution once async work completes. However, it's difficult to hide all the complexity of asynchronous programming behind a couple keywords, and there are a host of pitfalls and gotchas that you should be aware of. Without proper tooling, it's all too easy for any one of them to sneak up and bite you.

  Read more →

• Upgrading NServiceBus handlers to async/await

  Written by Particular Team on October 27, 2016

  In order to support the async/await keywords in NServiceBus 6.0, we had to make the first ever breaking change to the message handler API. We realize that this is a big change, and it's not one that we made lightly. The move to async/await required that the Handle method signature return a Task instead of void. At the same time, we replaced IBus with context-specific parameters to make it clearer which messaging operations are available from within a message handler. In order to make the conversion process as easy as possible, we've prepared a screencast that demonstrates how to convert a message handler from the previous syntax to the async-enabled API in NServiceBus 6.0.

  Read more →

• A new era for MSMQ scale-out

  Written by Weronika Łabaj on October 20, 2016

  Scaling out a web server is easy. All you have to do is stand up a bunch of web servers behind a load balancer like HAProxy and you're covered. Unfortunately, it hasn't been quite as easy to scale out MSMQ-based NServiceBus systems. That is, until now.

  Read more →

• A promise is only as good as the code that makes it

  Written by Daniel Marbach on September 29, 2016

  

  When I make a promise to someone, I do my best to keep it. If I'm pretty sure I won't be able to do something, I don't make any promises about it. Instead, I say I'll try to address it eventually. It's all about managing expectations. In some ways, a promise is like a software interface — a kind of contract between the other person and me. With asynchronous computations, we make promises in software too. They are similar to the promises you and I make, representing operations that haven't happened yet but are expected to happen in the future. In JavaScript, for example, there is an explicit Promise construct. In .NET, this is done with the System.Threading.Task class. Unfortunately, not everyone takes promises seriously — both in real life and in software.

  Read more →

• MSMQ performance improvements in NServiceBus 6.0

  Written by David Boike on September 21, 2016

  MSMQ was the very first NServiceBus message transport, and while not overly flashy, it got the job done. You could almost call MSMQ a finished product because, while it's updated with each Windows release, it doesn't really change much. It's solid, reliable, dependable, and overall, it Just Works™. One of the biggest changes we made in version 6.0 of NServiceBus (V6) is that the framework is now fully async. The thing is, the MSMQ's API in the .NET Framework hasn't been updated to support async/await, so what could we do for the MSMQ transport in NServiceBus? Make it go faster anyway. That's what.

  Read more →

• NService... umm, where's the bus?

  Written by Tim Bussmann on September 12, 2016

  

  With the upcoming version 6 of NServiceBus, we bid the IBus interface farewell and in its place, welcome a new wave of context-specific interfaces that are more intuitive and easier to test.

  Read more →