Fixing Assembly BindingRedirects when using NServiceBus.Host

Are you using NServiceBus.Host and after updating some NuGet packages the endpoint refuses to start? Read on for the solution

 

This post is only relevant for you if you’re using NServiceBus.Host to host your endpoint(s).

The problem

When you update some of the NuGet packages in your solution, you might find out that your endpoint suddenly refuses to start. In the debugger you will usually only get two signs of what might be wrong. The debugger breaking

And a message in the Debug Output:

An unhandled exception of type 'System.InvalidOperationException' occurred in NServiceBus.Host.exe
No endpoint configuration found in scanned assemblies. This usually happens when NServiceBus fails to load your assembly containing IConfigureThisEndpoint. Try specifying the type explicitly in the NServiceBus.Host.exe.config using the appSetting key: EndpointConfigurationType, Scanned path: \bin\Debug\

As soon as you hit Continue (F5) the process will shutdown without giving you further insight.

The analysis

You can skip to the solution if you already know it’s a binding redirect issue, even though you have added the redirect to the app.config.

Before investigating further, make sure “Just My Code” is disabled in the Visual Studio Debugging Options.

As well as ensuring that breaking on CLR exceptions is enabled. With OzCode (a Visual Studio Debugging Extension I personally don’t want to live without) it’s a simple click of a button.

Now, debug the endpoint once more from within Visual Studio.
You should get a ReferenceTypeLoadException in the debugger.

Open the exception details and drill into the LoaderExceptions. You will get an exception message similar to mine.

Could not load file or assembly 'log4net, Version=1.2.11.0, Culture=neutral, PublicKeyToken=669e0ddf0bb1aa2a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

It seems that an assembly (or a binding redirect) is missing. You check both and come to the conclusion it should be fine. The assembly and a matching binding redirect is in your app.config file, it’s expected to work.

The problem is, that NServiceBus.Host.exe has it’s own config which is missing the binding redirects from your app.config.
Why didn’t this happen before, you ask? My understanding is, that you had the same version of the now missing assembly (in my case log4net) as NServiceBus (or one of the extensions). Now that you updated yours to a newer version they don’t match.

The solution

The easiest solution I came up with is the following. Copy your app.config file over the NServiceBus.Host.exe.config in your output folder. This way NServiceBus knows the binding redirects and starts properly.

You can easily achieve this by adding the following line in the “Post-build event command line” in your project.

copy "$(ProjectDir)app.config" "$(TargetDir)NServiceBus.Host.exe.config"

Are you using OctoPack to automatically create a deployment package without a detailed .nuspec file?
Simply add a file called NServiceBus.Host.exe.config to the root of your project. Set “Copy to Output Directory” to “Copy if newer”.
Add the following content to make it a valid xml.

<?xml version="1.0" encoding="utf-8" ?>
<configuration/>

The empty file will be replaced by the post build step from above. Adding the file to the project tells OctoPack to add it to the deployment package.

Now your endpoint should be fixed.

Thanks to the people at Particular, the makers of NServiceBus, who helped me in their gitter channel with all my questions while migrating from v5 to v6.

Please comment if you need more advise or something is unclear.