Fix testhost build with different libraries and host configurations

[elinor-fung]

• Separate host configuration from normal configuration
• Propagate host configuration to libraries so that the testhost build can find the correct host binaries
• Allow specifying host configuration in build script

Fixes #73777

These two are equivalent and will result in a testhost layout with a checked runtime, release libraries, and debug host:

./build.sh clr+libs -rc checked -lc release
./build.sh clr+libs -rc checked -lc release -hc debug

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

• Separate host configuration from normal configuration
• Propagate host configuration to libraries so that the testhost build can find the correct host binaries
• Allow specifying host configuration in build script

Fixes #73777

These two are equivalent and will result in a testhost layout with a checked runtime, release libraries, and debug host:

./build.sh clr+libs -rc checked -lc release
./build.sh clr+libs -rc checked -lc release -hc debug

Author:	elinor-fung
Assignees:	-
Labels:	area-Host
Milestone:	-

[ViktorHofer]

We were hoping that it's OK for the host to use the same configuration as the runtime.
Do we need yet another component specific configuration set?

In the past we were using the prebuilt host packages which were release only.

[vitek-karas]

I think it would make sense to default the host to the same config as the runtime, unless explicitly overwritten.
I could also see us making it less of a first class thing - so maybe just an msbuild property or something like that.
But I would like to have the option to build Release runtime with Debug host. Host development actually involves running lot of managed code (all our tests are in C#), and running those on Debug runtime is really slow. So from my perspective, the change should fulfill two needs:

• Fix the problem that testhost is broken in some configs
• Maintain the ability to build Debug host and Release runtime (but not necessarily as a first class thing)

What is the exact mechanism for specifying the host config is not that important to me. I obviously like what Elinor did here, but if other's would like to have a more hidden setting, I think that's be fine as well.

[ViktorHofer]

My main concern with this change is that introducing more configurations per component introduces build complexity and without CI validation makes it prone to be broken. We already live with a difficult matrix as the CLR runtime has three configurations (Debug, Checked, Release) and mono has two (Debug, Release) and those need to paired with the libraries configurations (Debug, Release). If we would now also want to add CI protection for the different host configurations with the different runtime and libraries configurations then we would likely increase our machine quota noticeably.

@elinor-fung besides the general goodness of this change, is its intent to enable different host configurations just locally or do you also plan to add CI protection for it?

[elinor-fung]

The two needs Vitek called out are exactly what I had in mind.

It seemed more natural to me to have it completely separate rather than defaulting to the runtime config, We could certainly make it less of a first-class thing - basically remove the changes I made to the build scripts. I preferred it being an explicit option, as its omissions seems to have caused some confusion where people expect rc and lc to cover all binaries, so it is kind of weirdly an option by omission right now. (And I thought having it just made for a better dev experience.)

The different configurations already exist for the host today (and are combined with different runtime and libraries configurations), so the matrix is the same. Or are you only specifically talking about just creating the libraries testhost layout? I was not planning on changing the libraries test runs in CI to use a different host configuration, as I don't think that is particularly valuable validation.

[ViktorHofer]

Or are you only specifically talking about just creating the libraries testhost layout?

Right, I was referring to the testhost which until recently always used Release bits (from the nuget package). If we don't plan to change and validate a different testhost host configuration in CI then most of my concerns can be ignored.

Don't get me wrong, I think this change is good. I just wanted to make sure that we don't unnecessarily add complexity to the already non trivial configuration build system.

[elinor-fung]

Okay, I am going to leave this as-is then (with no plans to add CI configurations).

[elinor-fung]

Failures are:

• Mono crash in System.Net.Requests tests on linux-arm64 #74667
• [Tests] System.Net.Quic.Tests System.Exception : Failed to create MsQuicApi instance #74952