I uploaded the application i am using in .net core.
can you please outline it here what you are saying here. I have not receiving anything regarding support case
Support emails are coming from
email@example.com. If you have that email blocked, you will not receive anything. Please check your spam as well.
If you have old ASB endpoint publishing and the new ASBS endpoint receiving locally, but not in Azure it could mean that they are not using the same namespace.
- Check the namespace used by publisher and subscriber is the same namespace when deployed to Azure
- If deployed to IaaS (VMs), validate there are no blocked ports (TCP 5671).
- The code you’ve supplied is showing the subscriber, but not the publisher. If you can, provide a simple repro that has nothing to do with your project and scoped solely to pub/sub issue.
In case it’s not a namespace, I’d ask to share your namespace infor, but this should NOT be done over a public forum… hence the support case. I’m quite confident there’s an issue with the deployment rather than the transport. The code is the same code and should work.
Excuse my ignorance but I have not blocked that email and I have not received no email from firstname.lastname@example.org
I don’t think it is a issue with the namespace. THe publisher is using the same code as the .net core one
the following is the namespace:
Better yet, provide me with an exmaple with NSB 6 and NSB 7!
Absolutely. Here’s a result of a sample app you can find here.
You will need a connection string specified via environment variable called
AzureServiceBus_ConnectionString or via any other means.
In case you find any bugs with the ASBS transport, please raise those in the following repository.
Would also suggest to review why you haven’t received support emails as that will affect you in the future when you’ll try to contact support.
One thing, I notice that the publish is different. In NSB 6 I am using JsonSerializer but I see that you are using NewtonsoftSerializer. In NSB 6 I am using NServiceBus.Azure.Transports.WindowsAzureServiceBus 7.2.6 and you are using 8.0.3
would that be the problem?
Can you test with those settings to see if it works
Updated the sample to use sender with NSB v6 and unobtrusive mode (removed Messages project).
Note use of
RemoveAssemblyInfoFromMessageMutator - this is to ensure that messages coming from Publisher assembly can be processed by Subscriber. Pub/sub works fine.
Note: 7.2.6 is not the latest supported patch version. You should use 7.2.12
In caseit’s still not working, I highly recommend to use support channel to determine what’s different about your setup.
I have setup my project exactly as yours. But I still cannot receive messages once it goes over to azure. I consume messages if i run everything locally.
I will upgrade NServiceBus.Azure.Transports.WindowsAzureServiceBus to 7.2.12 and see if that fixes it
I upgrade to packages 7.2.12 and still not working. Below is the packages that I am using. I have opened the firewall for the port and nothing.
- package id=“NServiceBus” version=“6.3.4” targetFramework=“net461” />
- package id=“NServiceBus.Autofac” version=“6.0.1” targetFramework=“net461” />
- package id=“NServiceBus.Azure.Transports.WindowsAzureServiceBus” version=“7.2.12” targetFramework=“net461” />
- package id=“NServiceBus.CustomChecks” version=“2.0.0” targetFramework=“net461” />
- package id=“NServiceBus.Heartbeat” version=“2.0.0” targetFramework=“net461” />
- package id=“NServiceBus.Metrics” version=“2.0.0” targetFramework=“net461” />
- package id=“NServiceBus.Metrics.PerformanceCounters” version=“2.0.0” targetFramework=“net461” />
- package id=“NServiceBus.Metrics.ServiceControl” version=“2.0.1” targetFramework=“net461” />
- package id=“NServiceBus.Serilog” version=“3.0.3” targetFramework=“net461” />
Seems to be a general issue with Azure Service Bus, I check with other colleagues and they are not able to consume messages for newly created subscriptions
I used the sample from @SeanFeldman, setup the V6 endpoint in the cloud for simplicity reasons in IaaS and ran the v7 subscriber on my local box. As you can see below the communication works fine
So I think it has something to do with the network connection between the endpoint running in the cloud and your local environment.
If it run on my local machine it works fine. I can consume events. However I took the SubscriberASB and waiting for events to be consumed and the handler does not fire. NSB in Azure sending events
Now I dont know if it is NSB or AzureServiceBus
As much as I would wish to be a Server and PaaS whisperer, I’m not. It seems that we are stuck in a ping pong between us repeating it works in our repros and you repeating it doesn’t without giving us much more details. So I suggest we look into this deeper by going into a call (send me an email to daniel dot marbach at particular dot net) and discuss this issue further in detail. If you prefer continuing on this manner in an asynchronous fashion I suggest you provide us more details like
Check the topology and the rules on the broker if the subscription for the endpoint exists
and anything else you can give us to be able to track this down
Geremia and I had a call. The scenario was the following:
When he ran his .NET Core application together with the v6 application on the same box the event was delivered. When he ran over Azure it was not. To verify he executed a local integration test that calls a gateway. That gateway sends a command to an endpoint that handles the command. Once the command is handled an event was supposed to be published which the .NET Core Application was supposed to receive but it never did. We checked for competing consumer scenario which was not the case. We found multiple publishes in an event store subscription notifier that are not awaited. I suggested to add
GetAwaiter().GetResult() calls for now and then verify again. I also highlighted that we have now an analyzer package that detects such cases in the code