[Poison] TestHost files are leaking to source-built SDK

[crummel]

<File Path="zfwzfb3h.eei/dotnet-sdk-6.0.100-fedora.34-x64.tar.22/sdk/6.0.100/testhost.x86">
    <Hash>f59e4eb1ede8d7129706577530d05f04c93f29276d05e3055b74ffac553a229a</Hash>
    <Type>Hash</Type>
    <Match Package="/home/chris/tarball/packages/archive/art/Microsoft.TestPlatform.CLI.17.0.0.nupkg" PackageId="Microsoft.TestPlatform.CLI" PackageVersion="17.0.0" File="contentFiles/any/net6.0/testhost.x86" />
    <Match Package="/home/chris/tarball/packages/archive/art/Microsoft.TestPlatform.CLI.17.0.0.nupkg" PackageId="Microsoft.TestPlatform.CLI" PackageVersion="17.0.0" File="contentFiles/any/net6.0/TestHost/testhost.x86" />
  </File>

i.e., dotnet-sdk-6.0.100-fedora.34-x64.tar.gz/sdk/6.0.100/testhost.x86 is byte-for-byte identical to the previously-source-built's Microsoft.TestPlatform.CLI.17.0.0.nupkg/contentFiles/any/net6.0/testhost.x86.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[crummel]

@omajid This seems like the most troublesome poison failure to me but I also think we can just delete these files out of the final Linux distribution and not lose any functionality (since these files don't even appear in the MSFT build). What do you think?

[omajid]

If deleting these files keeps the SDK functional, that works for me.

Should we look at a longer-term fix too, though?

[omajid]

One thing that's not clear to me: once we get bootstrap fully functional and we have .NET building using a previously self-built .NET SDK, will something be building Microsoft.TestPlatform.CLI? Or will vstest.console and testhost.x86 be copied as a prebuilt over to all subsequent builds?

[crummel]

Should we look at a longer-term fix too, though?

Yes, but I don't know that we'll have it ready for 6.0.100.

will something be building Microsoft.TestPlatform.CLI?

I believe this should be getting built out of vstest. I think the issue though is that we're including these in the SDK where the MSFT-built SDK does not (#2570), so really the resolution will just be to stop whatever is letting those files sneak in.

[NikolaMilosavljevic]

Not an issue anymore after dotnet/installer#15347