https://github.com/dotnet/corefx/issues/40523#issue-484261911

.assembly extern retargetable mscorlib
{
.publickeytoken = (7C EC 85 D7 BE A7 79 8E ) // |.....y.
.ver 2:0:5:0
}

If any assemblies loaded by MetadataLoadContext were built against some older versions of mscorlib, PathAssemblyResolver will fail to match any newer versions of mscorlib present in assemblyPaths, due to a public key token mismatch. PathAssemblyResolver already supports taking the most recent version for target assemblies with an empty public key token.

https://github.com/dotnet/corefx/blob/master/src/System.Reflection.MetadataLoadContext/src/System/Reflection/PathAssemblyResolver.cs#L80

Add support for most-recent assembly match when assembly being resolved is 'retargetable'.

This was fixed in .NET 5 - dotnet/corefx#40581. We did not take this change into .NET Core 3.1 since the evidence was not clear at that time that this would be a big problem.

Since the release of .NET Core 3.1, several WPF customers have reported that this is a blocking problem.

• https://developercommunity.visualstudio.com/content/problem/806211/wpf-apps-fail-to-compile-after-updating-to.html
• https://developercommunity.visualstudio.com/content/problem/845412/vs2019-164-fails-to-build-windowsdesktop-project-t.html
• Updating to 16.4 from 16.3.x causes build issues with WPF project file. wpf#2274
• After update to VS 16.4 projects stop compiling wpf#2277

We would like this fix backported to .NET Core 3.1 as part of an upcoming servicing update.

/cc @ericstj, @nguerrera, @rladuca, @steveharter