Comparing symbols using only one set of references can result in false differences due inconsistent compare strings

[ericstj]

Describe the bug

When APICompat is comparing libraries from different frameworks and only has one set of references, and those references differ on CoreLib, APICompat may generate identifiers that are not consistent

To Reproduce

Discovered in dotnet/wcf#5742 (comment)

While debugging I noticed the comparsion strings for the two sides differ:

System.Nullable<System.Int32> System.ServiceModel.Federation.WSTrustTokenParameters.KeySize.get
System.Int32? System.ServiceModel.Federation.WSTrustTokenParameters.KeySize.get

Roslyn has enough to resolve that System.Nullable<System.Int32> should be System.Int32? but it is not.

It seems like this is due to the fact that in this case, the left symbol references Nullable in System.Runtime 8.0 - but right hand side has System.Runtime in netstandard. The right hand side references do contain a facade for System.Runtime that can forward the type to netstandard, but roslyn doesn't appear to be resolving this. It could be due to the version mismatch (netstandard's System.Runtime is version 4.1.2.0).

It's pretty unusual to do this type of comparison where a package replaces a framework specific asset (net8.0) with a more generic asset (netstandard2.0) and in general this comparison is not compatible from a consumption side of things (consuming net8.0 in netstandard2.0) but it is compatible from a production perspective.

[ericstj]

Looks like this is due to us not providing references for the left-hand-side.

sdk/src/Compatibility/ApiCompat/Microsoft.DotNet.PackageValidation/ApiCompatRunnerExtensions.cs

Lines 41 to 44 in b6c4b38

	if (leftContentItems[0].Properties.TryGetValue("tfm", out object? tfmObj) && tfmObj is NuGetFramework leftTargetFramework)
	{
	fallbackAssemblyReferences = rightPackage.FindBestAssemblyReferencesForFramework(leftTargetFramework);
	}

If I force the compiler to use the same references that we use for the right-hand-side (even though the framework is not compatible) It is enough to avoid this error.