BindingRedirects not generated for a specific reference

[AbhitejJohn]

In the attached the solution, the AutoBindingRedirect isn't generating redirections for "System.Buffers" causing runtime failures.
Here is the dependency graph showing the disparity

1. StreamJsonRpc 2.0.52-alpha -> Nerdbank.Streams 2.0.165-beta -> System.Buffers (>= 4.5.0)
2. StreamJsonRpc 2.0.52-alpha -> System.Memory 4.5.1 -> System.Buffers (>= 4.4.0)

Now System.Memory 4.5.1 depends on 4.0.2.0 of System.Buffers.dll(which is in 4.4.0 version of the package) and since the version is resolved to 4.5.0 because of 1. that drops 4.0.3.0 in the artifacts folder.

This is a Class Library project targetting net461 and is on the new project system. Any suggestions for a workaround would be really useful.
BindingRedirectIssues.zip

[AbhitejJohn]

Got this working with a manual specification in an app.config file for now.

[livarcocc]

@dsplaisted can you take a look?

[dsplaisted]

It looks like this is the same issue as here: https://github.com/dotnet/corefx/issues/32457

[mgravell]

And certainly the same as https://github.com/dotnet/corefx/issues/32511 (ours is the dup, yours is older)

[AArnott]

I just hit this myself. It took me a day to track down why things were failing since they were cross process and I was looking in all the wrong places. Please fix.

[AArnott]

To clearly document the workaround, add an app.config file to your project with (at least) this content:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <!-- .NET SDK bug: we shouldn't have to explicitly set this.
          https://github.com/dotnet/sdk/issues/2547 -->
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Buffers" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.3.0" newVersion="4.0.3.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

[jwfx]

@dsplaisted What is the state of this issue? Is this actively being worked on? Is there an official workaround or should everyone manage their binding redirects manually like shown above?

[dsplaisted]

No, we're not actively looking at this or planning to fix this in the SDK. Generally the solution is to update to the fixed packages.

[NickCraver]

For anyone else hitting this, I was also surprised to learn DLLs from NuGet packages aren't considered in ResolveAssemblyReferences by default. I had to explicitly enable this (very slight 1-2 sec perf impact at our ~500 project scale):

  <PropertyGroup>
    <FindDependenciesOfExternallyResolvedReferences>true</FindDependenciesOfExternallyResolvedReferences>
  </PropertyGroup>

...and then we're getting 17,000+ new redirects which we thought were being generated before. Basically: everything from NuGet. Cross-referencing back to several I've had to fix manually (encountered at runtime) the last few months, every single one was generated. This happens due to a skip in the reference table in MSBuild here: https://github.com/dotnet/msbuild/blob/b84faa7d0dfb42daedca5c244f73f0b07e1135d7/src/Tasks/AssemblyDependency/ReferenceTable.cs#L1692

cc @rainersigwald (I know I saw an identical issue in the MSBuild repo when digging into this, but been searching for half an hour and can't find it again).

[rainersigwald]

That's interesting because common.targets should set that to true for you when you generate binding redirects:

https://github.com/dotnet/msbuild/blob/b84faa7d0dfb42daedca5c244f73f0b07e1135d7/src/Tasks/Microsoft.Common.CurrentVersion.targets#L2349

[NickCraver]

Update on the above: I was missing this due to .gitignore hosting VSCode search. In a port ages ago we actually had FindDependenciesOfExternallyResolvedReferences explicitly disabled in the repo. So indeed that target works just fine - leaving this comment here in case anyone stumbles across the same cause/behavior later!