I’ve finally found the root cause.
In my other thread I’ve slimmed down which assemblies that NSB can load during startup.
The issue is because NServicebus.Callbacks.dll was excluded.
Today the documentation says:
During the scanning process, the core assembly for NServiceBus (
NServiceBus.Core.dll) is automatically included since it is required for endpoints to properly function.
You might want to add that the Callback assembly must be included for requests to properly function. It was a bit hard to find the cause since the request just hangs and the log just prints “No handler can be found for [TheResultMessage]”.
To reproduce it, take any of your samples and do the following:
endpointConfiguration.AssemblyScanner().ExcludeAssemblies("NServiceBus.Callbacks.dll");
(In our code, we loop through all AppDomain assemblies and exlude all which are not handler assemblies).
Personally I think that the whole assembly process is backwards. Why not just have a AddHandlerAssembly method in the assembly scanner (which means that no assemblies should be automatically added). Most devs know which assemblies to include, but it’s harder to understand which ones must be exluded. That also improves the startup time since everyone that wants to exclude assemblies must scan through all assemblies (or files) to be able to exclude everything that doesn’t contain handlers, while for AddHandlerAssembly no scanning is required at all (and you typically want to include a lot less assemblies than you must exclude, especially in .NET Core projects).