Use live assets to construct the testhost

[ViktorHofer]

externals.csproj is the remaining depproj file that we want to get rid of and replace it with using live assets where applicable. The project is currently responsible for:

• Binplacing the Microsoft.DiaSymReader.Native package into the shared framework.
  - Restoring the host packages and binplace them into the testhost and runtime folder.
• Copy runtime (coreclr & mono) assets into the testhost and runtime folder.
• Swap IL version of corelib with native one.

Most/all of this work could be replaced by leveraging the same infrastructure that the installer tests use to assemble the test layout to test against. Also see discussion in https://github.com/dotnet/runtime/pull/40172/files#r465090284.

cc @ericstj @jkoritzinsky @akoeplinger @safern @Anipik

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. Please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @safern, @ViktorHofer
Notify danmosemsft if you want to be subscribed.

[am11]

@ViktorHofer, @jkoritzinsky,

Background

I have an LTTng tracing test that requires dotnet(1) in the helix environment to load assembly, because corerun has some issues with the debug build (#56888) that is not reproducible with corehost's debug build. The corerun issue can be fixed in future but it feels like there is still a potential benefit of testing at least some scenarios under src/tests (if not all) with the actual shipping host; corehost.

Current Situation

Currently the test infrastructure for src/tests provides CORE_ROOTin the default test script template. Most tests use the template and run on corerun. The script also provides a way for test project to provide a hook script, which gets called by the template and has CORE_ROOT at its disposal; this is done by CLRCustomTestLauncher mechanism.

However, if the test requires corehost (dotnet(1) and friends) instead of corerun, currently there is no first-class, OOTB facility provided for it. AFAIK, (and please CMIIW) the dotnet in helix environment's PATH is apparently not the one which was live-built, it is 'some' previous version. For example, src/tests/BuildWasmApps/Wasm.Build.Tests/data/RunScriptTemplate.sh works around this problem by obtaining a fixed corehost from xharness, and overwriting some files to test the latest bits (which were built with same commit as test) reliably.

Question

Is there a plan to provide opt-in mechanism for helix tests to package with dotnet, instead of corerun? so the author of test project can chose using something like <RequiresCorehost>true</RequiresCorehost>, and the 'send-to-helix' package will pack corehost instead of corerun (and complain if the host/pack subsets weren't built).

[ViktorHofer]

@am11 this issue tracks using live assets to construct the testhost which is what our libraries tests under src/libraries run against. It's very similar to how the src/installer tests work but underneath a fundamentally different infrastructure is used to assemble the testhost / vs the bundle layout (installer).

In src/libraries we don't use corerun, we use the shipping corehost (dotnet.dll). To discuss replacing corerun with corehost for runtime tests, please open a new issue to keep this one libraries specific. Tbh I don't understand why we still have three different layouts that we test against: libraries testhost, runtime tests CORE_ROOT, installer tests bundle layout.