Setting up a .NET Cloud Service Bus

So I was watching this Plurasight course:
https://app.pluralsight.com/library/courses/microsoft-azure-developers-what-to-use/table-of-contents … and it talks about all the different Azure enabled services . IaaS, PaaS, and even LaaS (i.e. server-less). I was following the instructor when I realize that I personally hadn’t setup an azure service bus app from scratch myself, so I decided to venture through.

I will be following these directions loosely as always:
https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-authentication-and-authorization

Azure Service Bus Setup

Logging to your azure portal, search for Service bus and give it a name, select a subscription type, location and hit create.

Once that is done , create your queue. You can select Message TTL, Lock duration, enable dup. detection, enable dead letter queue, and message sessions.

Console Application Setup

So we have a bus started and a queue that can manage incoming messages. Now we make an app that can run the process.

Start up a project for a .net core console App, nuget install Microsoft.Azure.ServiceBus, and then I just copy \pasted the code from the linked reference above. I adjusted the configuration and looked up why the article’s code was using GetAwaiter().GetResult() ( I don’t recall using it before), and turns it out its because when Task is only returned in order to wait for it, you can only call it this way.

Ran the program as is.

Ok so now my queue has 10 messages in it:

I found a page that has all the information for the attributes that should be in the message payload,
https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-messages-payloads as I wanted to see more details.

I also adapted the code slightly so that it can send , receive\abandon or receive\complete .

Now keep in mind I was tempted to use the queue’s PeekLock\Abandon functionality to get all messages and parse the ones I wanted, but that technology is for topics and I wasn’t trying to create a topic so I will link you here in case you are interested. This is when found an interesting issue which probably isn’t really an issue. The Queue client Register Message Handler will continue to retrieve the same messages over and over unless you complete them; abandoning them does not pull them out of the list. It also increases the delivery attempt count and if it goes past the queue’s max, it throws them into the dead letter count.

The DLQ (dead letter Queue) is interesting because its a subset of the parent queue, in order to call it you call the original queue name plus $DeadLetterQueue, but then also found that there is a EntityNameHelper.FormatDeadLetterPath , which is going to be the better way to get these messages. These messages have some interesting data like why they failed: