Open eb2tech opened 1 year ago
@eb2tech Thanks for your feedback regarding single-file deployments using NServiceBus.RabbitMQ. As you have discovered the Assembly.Location API is not currently compatible with single file application deployments.
We don't officially support single-file deployments for NServiceBus endpoints at the moment. It's kind of a Your Mileage May Vary sort of situation at the moment–if we by luck didn't use any APIs that won't work in a single-file deployment, then it will work great!
But we don't explicitly test for that. And since we don't test for it, even if it worked today, it would be really easy for it to regress tomorrow.
Running our entire test suite as a single-file deployment probably isn't going to be workable, so what we would probably need is a Roslyn analyzer that detected usages of APIs like Assembly.Location
that are going to cause you to have a bad time. Or such analyzers may already exist but we haven't enabled them yet in our global .editorconfig
files.
Either way, properly supporting single-file deployments is a larger effort than changing this one problematic API usage.
Describe the bug
Description
When an executable built as a single file deployment tries to start an endpoint, computation of nsbVersion in ConnectionFactory.cs, line 92 fails with a System.ArgumentException. The property System.Reflection.Assembly.Location is empty for single file deployments because there is no file location.
Expected behavior
nsbVersion (and rabbitMQVersion) are computed successfully and client properties are set.
Actual behavior
nsbVersion is not computed and fails with an ArgumentException.
Versions
8.0.3 Please list the version of the relevant packages or applications in which the bug exists.
Steps to reproduce
Take any sample application and create a single file deployment using dotnet publish. Then run the application.
Relevant log output
Additional Information
Workarounds
Possible solutions
Obtain version information from System.Reflection.Assembly.FullName. In fact, since the value seems to be used as an opaque string, simply use the assembly's full name or
typeof(Endpoint).AssemblyQualifiedName
. A System.Type's AssemblyQualifiedName is as precise as one can get, especially if the name is strong.Additional information