Runtime: Make conflict resolution eliminate old System.Native libs prior to rename

[ericstj]

https://github.com/dotnet/runtime/issues/33118 changed the name of all the native shims. This caused conflict resolution to no longer eliminate those old binaries, which would be preferred by interop.

Found in https://github.com/dotnet/extensions/pull/3077

We should make conflict resolution handle this. The simplest way may be to add these to PackageOverrides.txt /cc @dagood

[dagood]

The issue makes sense, but I'm not sure how to use PackageOverrides.txt to work around it.

Would we maybe push a super new version of these packages that drops the old content, or that adds a dependency on Microsoft.NETCore.Targets package as mentioned in https://github.com/dotnet/extensions/pull/3077#issuecomment-597320964?

For context: src/installer/pkg/projects/netcoreapp/pkg/PackageOverrides.txt.

/cc @NikolaMilosavljevic

[ericstj]

No need to push anything new. We're just missing more of the 1.x era packages from that list. See https://github.com/dotnet/versions/blob/a8a10f0cd00c274fb91a7b2e78f28a3a1411916c/build-info/dotnet/corefx/release/1.1.0/LKG_Packages.txt#L44-L112

[ericstj]

I'll pick this up since I already made a change for this.

[ericstj]

This doesn't appear to be sufficient. The PackageOverrides only has an effect when a file conflict is encountered. Since these files are no longer part of the framework, they are not in conflict.

To fix this we could do a few things:

1. Create fake entries in PlatformManifest to indicate that they are in the framework to force the conflict.
2. Change the behavior of PackageOverrides to always override even if a file is not in conflict.

/cc @dsplaisted

[safern]

I think number 2 should be the long term, but maybe we could provide number 1 as a quick workaround?

[ericstj]

Another option here, which is basically moving 2 into NuGet restore is https://github.com/NuGet/Home/issues/7344.

Agree that 1 is the best short-term option. @dagood @NikolaMilosavljevic what do you think?

[dagood]

I think (1) is reasonable. A few pointers for impl--the place the fake line config need to end up to get into the generated platform manifest is https://github.com/dotnet/arcade/blob/1ffbf7b1b3d4842d027aecda84e9ece2bb3855d0/src/Microsoft.DotNet.Build.Tasks.SharedFramework.Sdk/targets/framework.dependency.targets#L201 (may need a new parameter to support entries that aren't actually files on disk?), and I'd expect the fake entries to end up as an itemgroup in netcoreapp.depproj.

[dagood]

Well, alternative that may keep it local to this repo: hook after the target and append to the file. 😛

[NikolaMilosavljevic]

Well, alternative that may keep it local to this repo: hook after the target and append to the file. 😛

This seems like the best short-term option - easy to remove when a better one is ready, or needed.

[ericstj]

Another pointer for impl. Look at a 3.1 version of the file to see the full set of old names for these System.Native files. Here's the one from the 3.1.0 ref pack.
PlatformManifest.txt

[ericstj]

@NikolaMilosavljevic do you think you could pick this up?

[NikolaMilosavljevic]

@NikolaMilosavljevic do you think you could pick this up?

Yes, I'll work on this now.

[NikolaMilosavljevic]

Fixed with https://github.com/dotnet/runtime/pull/33988