System.Buffers version different between net45 and netstandardx

[arthur-conde]

I have an issue in a solution utilizing projects running on both .NET 4.7.2 and .NET Standard that reference the ASP.Net Core SignalR client libraries.

The netstandard projects end up depending on System.Buffers 4.5.0 which have an assembly version of 4.0.3.0. The net472 projects end up pulling in a reference to the dll inside lib/ref which has an assembly version of 4.0.2.0.

We have a tool that scans our assemblies and ensures its dependencies are available. I believe because of this mismatch, our tool is reporting that a dependency is missing, as it's expecting different versions of the same assembly.

Unable to load reference for System.Memory, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 Could not load file or assembly 'System.Buffers, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) WRN: Assembly binding logging is turned OFF. To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.

While we are currently ignoring this when it comes up, it's not a solution.

Are there any recommendations on how to resolve this?

[mletterle]

I've ran into this too, there really needs to be a new version of System.Buffers with the version numbers all aligned. The best work around I've found so far is to explicitly reference System.Buffers version 4.4.0 on the net472 project.

The root of this, is the fact that even though net472 is newer than net45 they are technically the same "framework" and so the NuGet package resolution prefers the net45 version over the netstandard version (even though net472's "compatibility" is closer to netstandard2.0 than net45).

The 4.4.0 version of the System.Buffers NuGet package doesn't have a full framework reference assembly, only netstandard versions. So it picks the netstandard reference assembly same as the netstandard project.

There are other workarounds if you can't downgrade, but at that point you're bypassing NuGet resolution all together.

Also related to the following NuGet issues:

NuGet/Home#7416
NuGet/Home#7385
NuGet/Home#5370

Related sdk issue: dotnet/sdk#1791

[GrabYourPitchforks]

cc @joperezr

[joperezr]

@arthur-conde I just tried your repro locally and I see what you are saying, so looks like System.Buffers package version 4.5.0 has the following two assets:

ref/netstandard2.0/System.Buffers.dll  // -> this one with Assembly Version 4.0.2.0
lib/netstandard2.0/System.Buffers.dll // -> this one with Assembly Version 4.0.3.0

However, this should be completely fine, as the way that the .NET Core loader works, if an assembly compiled against 4.0.2.0 but got 4.0.3.0 at runtime, the loader will load this assembly just fine because the version is greater. In fact, in servicing this is usually the way we service OOB packages in which we usually just rev' up the implementation assembly's version, but not the reference assembly. Can you elaborate a bit more why is it that this is a problem for you? Does this tool that you run take into consideration the .NET Core loader rules of when its ok to use a different version?

[adamsitnik]

@ericstj is there anything we could do to align the version numbers?

[joperezr]

not sure what you mean about aligning version numbers but we don't build this package any longer so no change to modify this on 5.0, all we could do is in servicing and we don't really have the option to downgrade an implementation assembly version and increasing the assembly version of the ref could cause many other issues, so I'm more interested into understanding why is this a problem today before we decide what the fix should be or whether we should do it.

[adamsitnik]

not sure what you mean about aligning version numbers but we don't build this package any longer so no change to modify this on 5.0, all we could do is in servicing and we don't really have the option to downgrade an implementation assembly version and increasing the assembly version of the ref could cause many other issues

thanks for the explanation, I forgot that this is the "special" package (I was hoping that we can provide some easy fix)

I'm more interested into understanding why is this a problem today before we decide what the fix should be or whether we should do it

very good point! @arthur-conde could you please respond to the question asked by @joperezr above