Microsoft has recently released .NET 5 what is the scope of support from Particular on this?
Seems that in a NET 5 container the ServiceBus transport doesn’t work, is anyone working on the release of the NET 5 packages?
Welcome back @Riaan,
as said by @laila.bougria here, we’ve done extensive tests on the .NET 5 runtime, but only initial tests on the C# 9 language features. We’re actively working on adding .NET 5 to our support platforms.
What do you mean by:
Can you give me more details?
Cheers,
.m
Hey @mauroservienti
I tried searching for net 5 specific mentions in the forum but didn’t find so thanks for the link indeed records would be nice in messages.
The specific issue we faced that with net 5 locally there was no problem the endpoint runs and processes perfectly happy, but when running in the net5-buster container it was not able to pull messages from the transport (ASB) in our case.
Attached is a screenshot from our logging I don’t, unfortunately, have a more detailed log, but I could try to investigate further if this is not sufficient.
@Riaan do you have a custom critical error implementation? Critical Errors • NServiceBus • Particular Docs
This leads me to consider an environmental issue. If this would be a .NET 5 issue strictly, it would not run locally or anywhere else. What’s “net5-buster container”? What’s this environment the endpoint is failing to fetch messages?
Hi @SeanFeldman
When I say net5-buster container it is the Linux Debian container tagged as buster on dockerhub… ASP.NET Core Runtime - Docker Hub if you look at the tags, it seems that within none of the Linux based containers work.
Hi @Simon_Cropp
Yeas we do have a custom implementation, see the snippet
_endpointConfiguration.DefineCriticalErrorAction(
async context =>
{
try
{
// place custom handling here
Logger.Error(context.Exception,
$"Critical Error in Endpoint [{EndpointName}]. Error: {context.Error}");
await context.Stop()
.ConfigureAwait(false);
}
catch (Exception ex)
{
// ignored
Logger.Error(ex, $"Error while stopping Endpoint [{EndpointName}].");
}
// Kill the process on a critical error
string output = $"NServiceBus critical error:\n{context.Error}\nShutting down.";
Environment.FailFast(output, context.Exception);
});
The logger is just NLog
that DefineCriticalErrorAction actions looks ok. I was trying to work out why the stack trace was not showing up for you in Seq. how are you mapping nlog through to Seq?
I’m not aware of anything that would prevent the transport from running with .NET 5.
Running outside of docker works just fine which leads me to question either the environment aspect. If you try native (SDK) code to receive a message, does that code work for you? Note you’ll need Microsoft.Azure.ServiceBus package rather than Azure.Messaging.ServiceBus.
@Simon_Cropp
I will find that code if you believe it to be helpful, but looking at the LoggerName this is coming from inside NServiceBus.
Specifically, the NServiceBus.Transport.AzureServiceBus.MessagePump might be that we have a bad implementation connecting the NServiceBus logger to NLog, but doesn’t seem that it is bubbling through to the CriticalErrorAction
Will have to give me a moment to investigate the logger config
Hi @SeanFeldman
I also believe it is environmental, I will take some time this week to investigate further with the native SDK, rather than NServiceBus transport and update here accordingly.
u are correct, it is a bug in MessagePump pass missing exception by SimonCropp · Pull Request #219 · Particular/NServiceBus.Transport.AzureServiceBus · GitHub