NServiceBus for dummies who want to be smarties 2

NServiceBus for dummies who want to be smarties 2… second post, this time on how to do some more stuff with NServiceBus.

How to do stuff when the service starts

Make a class implement IWantToRunAtStartup, e.g. like so:

How to speed up delivery of messages that are transient in nature

If your message contents get stale after a short period of time, it makes no sense to use reliable messaging where messages are written to disk before the message queueing service attempts to deliver the messages to their destination. Therefore, to be true to the transient nature of the messages and speed up delivery, you can decorate some of your messages with the [Express] attribute. E.g. like so:

How to make messages expire after some amount of time

If you know your message content does not make sense after some period of time, say one hour, just decorate your message with the [TimeToBeReceived] attribute – e.g. like so:

Note that the argument to the attribute must be Parseable – unfortunately C# does not allow for calling e.g. TimeSpan.FromHours(1) in the attribute initializer.

How to stop logging all kinds of noise to the console

Logging is good, but not all the time. To disable all of NServiceBus’ logging, just make your endpoint config implement the interface IWantCustomLogging and do nothing in the Init method – e.g. like so:


That concludes today’s “NServiceBus for dummies who want to be smarties”. This was about how to add some more life to your service. Next post will be about the question: where do the messages go?

2 thoughts on “NServiceBus for dummies who want to be smarties 2

  1. I’m really enjoying this series so far. Next up (please): how to get NServiceBus to use a database to store messages. I’m conceptually missing that whole part – when it’s required, when it’s not, what it means to MSMQ when a DB is involved. But quite aside from that, keep these focused posts coming, and thank you.

  2. I don’t think I can see why you would want to store messages in a DB? Messages are a means of communication between parts of your application, and as such are not really candidates for being treated as entities.

    Dru Sellers did a series of posts called “Why messaging”, you should really check them out – intro is here, and a really good description of what constitutes a message is here.

    You can find all his Codebetter-posts here.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.