Azure Service Bus with NSB 7 and .net core



Hello Folks

I am having a issue. I have created a .net core application that uses NSB7 and uses AzureServiceBus as Transport. The application runs and creates the queue but no messages are being placed on the queue.

The other applications are running on the full .net frameworks and NSB 6. These application are publishing messages. This messages are successfully consumed by other consumers running with NSB 6. However NSB 7 does not receive any messages from NSB 6. NSB 7 does receive messages from itself (NSB7)

Any ideas why when publishing from NSB 6 the messages does not arrive to the queue that has NSB7

(Sean Feldman) #2

Hi @gjek,

In general, it would be much better to go through support channel to troubleshoot this kind of issues.
You can post your question to support here:

Are you using NServiceBus.Azure.Transports.WindowsAzureServiceBus or NServiceBus.Transport.AzureServiceBus?



I am using NServiceGus.Transport.AzureServiceBus



Interestingly in my local machine I am running a console application with NSB6 and do a publish and I am able to pick it up in the console application with NSB 7.

However when it is deployed to Azure the subscriber is not getting the messages. Subscribers with NSB6 do get the messages in Azure cloud

(Sean Feldman) #5

@gjek could you raise a support case with a reference to this thread?
The transport is still in preview, so not rulling out a posibility of a bug. Either way, it’s much better to troubleshoot over support channel.

Thank you,

(Sean Feldman) #6

When using NSB6, you’re using the NServiceBus.Azure.Transports.WindowsAzureServiceBus transport. It’s important to ensure NSB6 endpoint is using the right topolgoy (see details here). If NSB6 endpoint is already on Forwarding topology, then let’s discuss over support case to get more details.



NSB 6 with Azure Service Bus is using ForwardOnly Topology.

I have created the support ticket via the link that you provided me.

I hope to hear from you soon


(Daniel Marbach) #8

Hi @gjek

What kind of sanitization strategy are you using? For example, if you use ValidateAndHashIfNeeded topics that are longer than 50 chars will be hashed with a deterministic GUID using MD5. In order to be able to subscribe to that topic the endpoint using the new transport needs to have RuleName and SubscriptionName shortener that matches the sanitization strategy used in the v6 endpoint. Only then they can properly communicate.

Here is a commit that demonstrates that




I am not using any sanitization strategy. All endpoints are less than 50 chars. I have a unit test to ensure that topics are less than 50 chars


The code I am using is the following

public static class NServiceBusExtensions
        const int MaxEntityName = 50;

        public static IServiceCollection RegisterNServiceBus(this IServiceCollection services)
            IEndpointInstance endpointInstance = null;

            var endpointConfiguration = new EndpointConfiguration("CareVisit.EventIntegration");



            endpointConfiguration.Conventions().DefiningEventsAs(t => t.Namespace != null && t.Namespace.EndsWith("Events"));

            var transport = endpointConfiguration.UseTransport<AzureServiceBusTransport>();
            transport.SubscriptionNameShortener(n => n.Length > MaxEntityName ? MD5DeterministicNameBuilder.Build(n) : n);
            transport.RuleNameShortener(n => n.Length > MaxEntityName ? MD5DeterministicNameBuilder.Build(n) : n);

            services.AddSingleton<IMessageSession>(sp => endpointInstance);

            endpointConfiguration.UseContainer<ServicesBuilder>(c =>

            endpointInstance = Endpoint.Start(endpointConfiguration).GetAwaiter().GetResult();

            return services;

        static class MD5DeterministicNameBuilder
            public static string Build(string input)
                var inputBytes = Encoding.Default.GetBytes(input);
                // use MD5 hash to get a 16-byte hash of the string
                using (var provider = new MD5CryptoServiceProvider())
                    var hashBytes = provider.ComputeHash(inputBytes);
                    return new Guid(hashBytes).ToString();

(Dennis van der Stelt) #11

We’re not seeing anything weird that explain why messages aren’t sent. Can you please upload the entire solution somewhere? Perhaps GitHub or via a .zip file?


I get a error saying new users cannot upload attachments


I tried to email my solution but looks like your email server refused it saying malware was detected :frowning:

(Dennis van der Stelt) #14

@gjek I’ve increased your trust level on this forum, you should be able to upload files. Please try to remove any /obj/ and /bin/ folder though. If it’s .NET Core there should not be a /packages/ folder.


alright. I will upload again

#17 (522.9 KB)


a binary is missing that contains the events. but you can replace that with your own and test with azure service bus


if both console application run in my local machine I can publish events from NSB 6 and can consume the event in NSB 7.

But if I deploy NSB 6 to Azure and it publish messages then NSB 7 running on my machine does not consume the events.

(Sean Feldman) #20

From what I could read/deduct so far, it doesn’t seem to be transport issue. Check namespaces, validate entities and messages. There are several things that could be checked to facilitate troubleshooting (which were sent to you with the support case). Cheers.


Is there a diagnose or something with NSB 7?
I have tried everything and does not work. Everything works with NSB 6.