Why does a force downgrade causes an assembly load exception in .Net Core?

Question

I have a sample solution with a console and library project. Both reference the same nuget but a different version. The console project also has a reference to the library project. So the structure is like this:

- Solution
    - ConsoleApp
        - Project Reference: Library
        - Nuget: NServiceBus.RabbitMQ (5.2.0)
    - Library
        - Nuget: NServiceBus.RabbitMQ (6.0.0)
     

You can find the solution here.

Since Nuget uses the nearest wins rule, the nuget package that gets resolved is version 5.2.0. This is what I want, so far so good. But when I run the application and run a method of the Library I get the following exception:

Could not load file or assembly 'NServiceBus.Transport.RabbitMQ, Version=6.0.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c'. The located assembly's manifest definition does not match the assembly reference. (0x80131040)

In .NET Framework I would solve this with an assembly redirect. But that isn't available in .Net Core. I always thought that .Net Core solves this automatically by using the deps.json file. There I see the following statement:

"Library/1.0.0": {
    "dependencies": {
        "NServiceBus.RabbitMQ": "5.2.0"
    },
    "runtime": {
        "Library.dll": {}
    }
}

But still at runtime he tries to resolve the 6.0.0 version. I'm using the latest .Dot Net 3.1.X SDK.

I'm I doing something wrong or does this seem like a bug?

For the record, this is a simple sample project. The actual situation where I need this is much more complex. I also do understand that doing this can cause runtime exceptions while running the application.

Answer 1

It appears to be by design.

A little bit of searching, I found this: https://github.com/dotnet/fsharp/issues/3408#issuecomment-319466999

The coreclr will load an assembly of the version or higher than the reference. If the assembly discovered is lower than the reference then it fails.

Also this: https://github.com/dotnet/sdk/issues/384#issuecomment-260457776

downgrading the assembly version isn't supported on .NET Core

So, to confirm, I spent much more time than I intended looking/searching through https://github.com/dotnet/runtime. Eventually I found the assembly version compatibility method: https://github.com/dotnet/runtime/blob/172059af6623d04fa0468ec286ab2c240409abe3/src/coreclr/binder/assemblybindercommon.cpp#L49-L53

It checks all the components of the version separately, but if we look at just one, we can see what it's doing:

            if (!pFoundVersion->HasMajor() || pRequestedVersion->GetMajor() > pFoundVersion->GetMajor())
            {
                // - A specific requested version component does not match an unspecified value for the same component in
                //   the found version, regardless of lesser-order version components
                // - Or, the requested version is greater than the found version
                return false;
            }

As the comment says, the loader will reject the assembly if the assembly's version is lower than the requested version. In your case, assuming that the assembly version matches the package version (which it doesn't have to), your library is requesting version 6.0.0, but the assembly loader/binder, found version 5.2.0 on disk, which is lower. Hence, it rejects that dll, keeps looking, but then can't find a suitable version of the assembly on the probing path and eventually throws the FileLoadException.

What's not clear to me is if this assembly compatibility is checked only on the default assembly loader, or even if you add your own event handler to AssemblyLoadContext.Default.Resolving. You could try adding your own handler and when it requests the assembly of the higher version, you return the lower version assembly anyway. It might be a way to work around the issue.