NS2.0 AssemblyName.ReferenceMatchesDefinition() (dotnet/coreclr#10919)
This api was broken from its debut in 2.0 (and yet somehow
scored a 2.9% on .NET api catalog)
https://connect.microsoft.com/VisualStudio/feedback/details/752902/assemblyname-referencematchesdefinition-returns-true-even-though-the-parameters-dont-match
In 2012, the MSDN docs were changed to match its broken behavior:
Return Value
Type: System.Boolean
true if the simple assembly names are the same; otherwise, false.
Remarks
The comparison depends only on the simple assembly name. It ignores version, culture, and public key token.
A more accurate description would be:
This api takes the simple names of the ref and def.
Then it parses the simple names *as if they were*
full-blown assembly names with optional Version, Culture
and PKT (!)
Then it applies a RefToDef test to that name using a test
that's quite separate from the one used by the actual
CoreCLR loader (so any similarities between
it and the actual binding rules is purely coincidental.)
Oh, and that code assumes the Def name came from trusted
sources so if it's has a null Culture property, it NULL-AV's.
We could replicate this behavior on CoreRT (relying on
its own AssemblyBinder) but the more I progressed, the
more the venture failed to pass the laugh test (though
at least we got a nice AssemblyBinder cleanup
as a side effect.)
So what we'll do is make the api behavior match the
MSDN description (and likely come close enough to the compat bar)
but in a more straightforward fashion.
(The RefMatchesDef routine is used on one case - to
match assembly refs against a list of friend-access
assembly defs. So it's not quite dead code though
it probably should be.)
Commit migrated from https://github.com/dotnet/coreclr/commit/
f1f5986528158533874cd1f4d4a90a15a374d68b