System.Memory packages 4.5.3 and 4.5.4 deliver differing Framework assemblies versioned 4.0.1.1

[rainersigwald]

Description

There are two distinct copies of System.Memory, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51.

1. The one from version 4.5.3 of the package references System.Numerics.Vectors, Version=4.1.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
2. The one from package version 4.5.4 references System.Numerics.Vectors, Version=4.1.4.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a​​​​​​​

Since they have the same fully-qualified name, the .NET Framework loader will treat them as interchangeable. For instance, if a user has installed the former in the Global Assembly Cache, it will be loaded even if the latter is present on the load path.

This is the root cause of https://developercommunity2.visualstudio.com/t/Project-issues-after-1682-update-chil/1263614. Some users had the old assembly GACed and it caused an inscrutable failure in MSBuild on their machines (after we removed a binding redirect that was no longer generated after updating some of our references).

Regression?

Not really.

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[carlossanlop]

@ericstj @joperezr would you mind helping with this?

[ericstj]

This is due to servicing without changing assembly version, yet the assembly version of a dependency was changed. This could be fixed by merely shipping a new version of System.Memory with an updated assembly version.

Tagging subscribers to this area: @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

There are two distinct copies of System.Memory, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51.

1. The one from version 4.5.3 of the package references System.Numerics.Vectors, Version=4.1.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
2. The one from package version 4.5.4 references System.Numerics.Vectors, Version=4.1.4.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a​​​​​​​

Since they have the same fully-qualified name, the .NET Framework loader will treat them as interchangeable. For instance, if a user has installed the former in the Global Assembly Cache, it will be loaded even if the latter is present on the load path.

This is the root cause of https://developercommunity2.visualstudio.com/t/Project-issues-after-1682-update-chil/1263614. Some users had the old assembly GACed and it caused an inscrutable failure in MSBuild on their machines (after we removed a binding redirect that was no longer generated after updating some of our references).

Regression?

Not really.

Author:	rainersigwald
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	Future

[safern]

@ericstj based on your description it is a simple fix, should we service the fix?

[joperezr]

The fix is trivial, but we should check if it meets the bar or not since doing so may have other implications. For instance, System.Memory is a dependency of a lot of packages in Desktop, and increasing assembly version will introduce the requirement of binding redirects in users projects which we know can be a big pain point for many, and the only way to avoid this would be to service all packages above System.Memory so they get the assembly bump. It might just be easier to instruct customers to not GAC the old version and GAC the new one instead, or to avoid GACing if possible.