source-build: Remove Microsoft.DiaSymReader.Native prebuilt

[dagood]

Part of prebuilt removal: dotnet/source-build#885

I looked at the Core-Setup Microsoft.DiaSymReader.Native 1.7.0 prebuilt dependency. I don't believe the source for this package is public, so we can't remove it by adding the repo to source-build.

https://github.com/dotnet/core-setup/blob/855cd7611a68f849e041e13a7836f10eaa6e1ed4/src/pkg/projects/netcoreapp/src/netcoreapp.depproj#L16

Core-Setup redists the package's native DLLs in the Windows runtime packages. Not a problem for build from source: Windows is not a priority.

More interesting, the native DLL version info is included in the platform manifest file (in Microsoft.NETCore.App):

Microsoft.DiaSymReader.Native.x86.dll|Microsoft.NETCore.App||14.12.25830.2
Microsoft.DiaSymReader.Native.amd64.dll|Microsoft.NETCore.App||14.12.25830.2
Microsoft.DiaSymReader.Native.arm.dll|Microsoft.NETCore.App||14.12.25830.2

Removing this dependency would make source-build unable to produce the same platform manifest as the Microsoft build without workarounds. We could hard-code the values, or put these native DLLs through something like the ref-only prebuilt managed DLL infrastructure.

However, the source-built platform manifest file is already missing these entries, and more. This is because source-build only produces the manifest for the current platform, where the Microsoft build produces the manifest for all platforms. If this difference is ok, we can remove the dependency during builds from source without any concerns.

[dagood]

I started a thread about this with @ericstj, @dsplaisted, and @nguerrera a little over a week ago but I haven't had time to follow up on it. To open it up to more input, here's info from the thread:

[@dagood] I’m wondering what the consequences are for source-build’s [platform manifest] being different from the Microsoft build’s. Maybe self-contained publish for win-x64 by a Linux source-built SDK is a little broken, or something like that?

[@ericstj] PlatformManifest never impacts self-contained. With Self-contained you always have the “real” assets to resolve with.

The PlatformManifest is used for framework-dependent. It’s listing out all the things that are in the shared framework but not visible at build time so that conflict resolution can “know” to remove them.

Some of this is less important since the host now does some conflict resolution at runtime with version info from the deps file. I believe it’s still relevant for stuff that the host can’t resolve. For example: someone directly references a 1.0 copy of a native-shim package, so they get an app-local copy (in RID specific folder) of one of our native shims. How do we make sure this doesn’t downgrade the shared framework?

/cc @dleeapho @dseefeld @crummel for source-build impact.

[dagood]

Fixed by dotnet/core-setup#7346, in preview 8.