Use the "live" NETCoreApp shared framework in CoreCLR and Libraries tests

[dagood]

Now that the repo is consolidated, we can look at ways to reduce some redundant infrastructure around the shared framework.

Before consolidation, Core-Setup was downstream from CoreCLR and CoreFX. This means the crossgenned NETCoreApp shared framework produced by Core-Setup doesn't go through CoreCLR and CoreFX's tests.

CoreCLR tests do their own crossgen to set up a R2R testing infrastructure. I think CoreFX does something similar, but I'm not sure if it crossgens.

With consolidation, we could have CoreCLR and Libraries tests use the R2R shared framework prepared by Installer. This might save build time, and seems like it will remove some redundant infra so we don't have to maintain it.

The current Installer sharedfx generation infra might not be clean enough yet for this to work in a repo that has much higher dev workflow standards (IMO). I have concerns around incrementality and efficiency in a tight dev loop. I'm not active on that part of the infra quite enough to pinpoint the problems offhand, but I want to make sure we consider it before going all-in.

---

(I thought I remembered idea/plan in an issue or a roadmap, but I can't find it. Filing to make sure it's tracked regardless.)

/cc @trylek @stephentoub

[trylek]

/cc @jkotas @nattress @janvorli

[trylek]

Alluding to Davis' comment - CoreCLR way of crossgenning the framework is totally hacky too. My initial strawman was to switch this over to the SuperIlc tool I originally wrote for the purpose of local Crossgen2 testing - as one of its side effects it's capable of crossgenning framework (using both the legacy and new Crossgen) employing parallelization so it's quite a bit faster. As an additional bonus it would give us at least some code coverage for the tool too.

[jkotas]

current Installer sharedfx generation infra

I agree that it would make sense to use the installer sharedfx generation infra to produce the bits that the tests runs against (e.g. in CI).

I have concerns around incrementality and efficiency in a tight dev loop.

The tight dev loop should not be going through any of the crossgening, etc.

SuperIlc tool

SuperIlc is a test harness. I do not think it makes sense to use it to build the product.

[jkotas]

(Issues should be marked with a single area only: https://github.com/dotnet/runtime/blob/master/docs/issues-pr-management.md#scenarios-where-we-all-have-to-work-together)

[trylek]

Well, OK, I think that my point is - on the one hand we have super hacky code in

runtime/src/coreclr/build-test.cmd

Line 653 in a76c402

:PrecompileFX

or another copy in

runtime/src/coreclr/build-test.sh

Line 145 in a76c402

precompile_coreroot_fx()

or another copy in the installer pipeline. What would be your preferred way to get rid of this wasteful redundancy?

[Sorry about the issue tags.]

[jkotas]

Have just the one in the installer pipeline. The installer pipeline has to have it obviously.

And switch the tests to run against the bits produced by the installer pipeline. We have a test hole today in that we do not actually run tests against the bits that we ship (https://github.com/dotnet/corefx/issues/33958). Switching the tests to run against the bits produced by the installer pipeline (crossgened, signed, etc.) would fix that.

[safern]

Something to consider here is to run a set of libraries tests in the single PR pipeline when the installer subset is changed. Look at discussion: #1473 (comment)

[ViktorHofer]

Closing as done.

[ViktorHofer]

Reopening as I misread the title.

[ViktorHofer]

When ever we get to this we should make use of the shared framework's SDK functionality to dump the bundle layout onto disk and use that for both the runtime and libraries.

Moving to 7.0.