Linker produces colliding MVID for two different inputs

[vitek-karas]

See dotnet/runtime#45649 for more details.

This is inherently a Cecil issue, but tracking it here since we don't normally watch Cecil repo.

Adding to 6.0.0 for now - to consider this at least.

/cc @agocke

[vitek-karas]

#2384 brings the fix into main.
We should consider this for 6.0 servicing.

[filipnavara]

We should consider this for 6.0 servicing.

Just a heads-up. We discussed an unrelated issue on Discord and found out that assemblies in different Mono runtime packs now get different MVID despite identical IL code.

For reference, see these packages:
https://nuget.info/packages/Microsoft.NETCore.App.Runtime.Mono.osx-x64/6.0.1 https://nuget.info/packages/Microsoft.NETCore.App.Runtime.Mono.osx-arm64/6.0.1

Check it for System.Collections.dll, it is likely identical. Now try the same on 7.0 nightly builds and it's no longer identical.

[vitek-karas]

The new linker behavior should be:

• Identical input produces output with deterministic (meaning always the same) MVID
• Different input produces output with different MVID (this was not true before the fix as per above)

If anybody sees a different behavior then we need to look into that. So the question here is if the input to the linker was identical or not (note that identical IL is not enough, the above issue is that the dlls only differ in the architecture bit in the PE header, but otherwise have identical IL, those should still get different MVIDs).

The new linker also fixes the PDV checksum parts - so if for some reason the difference is only in the symbols, the dlls should not be identical (and should not get the same MVIDs).

[filipnavara]

I agree it should be checked carefully. Some of the assemblies are originally built as AnyCPU so I would expect them to be identical if everything is deterministic (including PDB paths). Note that Xamarin.Android apparently does some deduplication by MVID so the determinism across architectures should be tested somehow.