Make it possible to build just the shared framework projects or the out-of-band projects

[ViktorHofer]

Today the libs.ref and the libs.src subsets build both the shared framework and the out-of-band projects. The CLR team let us know that they would like to spend less time on building the libs subset and don't need the out-of-band projects like the Microsoft.Extensions.* ones being built.

I agree with that sentiment and we even had discussion in the past whether the out-of-band projects should even be moved into a separate repository. That shouldn't be necessary as writing out-of-band projects has become much easier with ongoing infrastructure investments like the pkgproj removal but it would be great if we could split the libs subset so that devs can intentionally build the shared framework projects or the out-of-band projects separately. Of course you still need to build the shared framework once before you can build the out-of-band projects as they rely on the shared framework live build.

I propose that we change the existing libs.ref and libs.src subsets to libs.sfx and libs.oob. The libs.ref subset shouldn't be necessary anymore as reference projects are already built incrementally together with the source projects.
In #64000 (comment) @joperezr expressed the desire to be able to still just build the refs to make it possible to launch VS as quickly as possible without building the shared framework source projects. That will continue to be possible but with a slightly different command, instead of build.cmd/sh libs.ref it will be build.cmd/sh libs.sfx /p:RefOnly=true. See #64000 (comment) for a more detailed explanation why only the refs of the sfx subset need to be built.

Ideally this will happen with the next infrastructure rollout (March 2022) as when #64000 gets merged this will just be a matter of removing the existing "libs.ref" and "libs.src" subsets.

cc @safern @joperezr @ericstj

[ghost]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Today the "libs.ref+libs.src" subsets build both the shared framework and the out-of-band projects. The CLR team let us know that they would like to spend less time on building the libs subset and mostly don't care about the out-of-band projects like the Microsoft.Extensions.* ones when building locally.

I agree with that sentiment and we even had discussion in the past whether the out-of-band projects should even be moved into a separate repository. That shouldn't be necessary as writing out-of-band projects has become much easier with ongoing infrastructure investments like the pkgproj removal but it would be great if we could split the libs subset so that devs can intentionally build the shared framework projects or the out-of-band projects separately.

I propose that we change the existing "libs.ref+libs.src" subsets to "libs.sfx+libs.oob". The "libs.ref" subset shouldn't be necessary anymore as reference projects are already built incrementally together with the source projects.
In #64000 (comment) @joperezr expressed the desire to be able to still just build the refs so make it possible to launch VS as quickly as possible without building the entire shared framework source projects. That will continue to be possible but with a slightly different command, instead of build.cmd/sh libs.ref" it will be build.cmd/sh libs.sfx /p:RefOnly=true`. See #64000 (comment) for a mroe detailed explanation why only the refs of the sfx subset need to be built.

Ideally this will happen with the next infrastructure rollout (March 2022).

cc @safern @joperezr @ericstj

Author:	ViktorHofer
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	7.0.0

[ericstj]

I'm supportive of this. Will it include the desktop compat shims that reference all the OOB packages, or will we exclude those in this case?

[ViktorHofer]

This already got implemented in main with #64000.

Today the shims aren't built in the libs.sfx subset, but in the libs.oob subset. Potentially this could change if we would check-in the by GenFacde generated facade source files and make sure that the OOB subset then later verifies that those generated files are up-to-date.

Opened #65997 to discuss that.