Update host test command execution logging: include PID on exit, remove confusing OK/FAIL, add caller name

[elinor-fung]

When launching a process to test, host tests write to the console on launch, wait for exit, and exit. Currently, they also log OK/FAIL based on the exit code and a parameter for whether failure is expected. All tests already do their own validation for if the command should pass/fail - having this extra logging is not useful and can be actively confusing, since it relies on tests also passing in that parameter (even though that is not used for actual validation/asserts).

This PR updates the logging to remove the OK/FAIL, include the PID on exit, and add the caller name (for test identification).

Example of existing logging:

[EXEC >] [....] [00:00:30.516] C:\repos\runtime\artifacts\tests\host\windows.x64.Release\sharedFrameworkPublish\dotnet.exe C:\repos\runtime\artifacts\tests\host\windows.x64.Release\ha\l24mjfq5.zpz\HelloWorld\HelloWorld.dll throw_exception
[EXEC -] [....] [00:00:30.520] Waiting for process 65220 to exit...
[EXEC <] [ OK ] [00:00:30.657] C:\repos\runtime\artifacts\tests\host\windows.x64.Release\sharedFrameworkPublish\dotnet.exe C:\repos\runtime\artifacts\tests\host\windows.x64.Release\ha\l24mjfq5.zpz\HelloWorld\HelloWorld.dll throw_exception exited with -532462766. Expected: non-zero

With this PR:

[EXEC] [00:01:22.797] [UnhandledException_BreadcrumbThreadDoesNotFinish]
       C:\repos\runtime\artifacts\tests\host\windows.x64.Release\sharedFrameworkPublish\dotnet.exe C:\repos\runtime\artifacts\tests\host\windows.x64.Release\ha\lfasw0g2.ynl\HelloWorld\HelloWorld.dll throw_exception
[WAIT] [00:01:22.802] [UnhandledException_BreadcrumbThreadDoesNotFinish]
       PID: 50836 - C:\repos\runtime\artifacts\tests\host\windows.x64.Release\sharedFrameworkPublish\dotnet.exe C:\repos\runtime\artifacts\tests\host\windows.x64.Release\ha\lfasw0g2.ynl\HelloWorld\HelloWorld.dll throw_exception
[EXIT] [00:01:22.947] [UnhandledException_BreadcrumbThreadDoesNotFinish]
       PID: 50836 - Exit code: 0xe0434352 - C:\repos\runtime\artifacts\tests\host\windows.x64.Release\sharedFrameworkPublish\dotnet.exe C:\repos\runtime\artifacts\tests\host\windows.x64.Release\ha\lfasw0g2.ynl\HelloWorld\HelloWorld.dll throw_exception

Contributes to #116520

cc @dotnet/appmodel @AaronRobinsonMSFT

[dotnet-policy-service]

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

[Copilot]

Pull Request Overview

This PR augments test command execution logging by passing the calling test method’s name into command invocations and updates exit-wait semantics in bundle tests. Key changes include:

• Added a caller parameter (via [CallerMemberName]) to RunTest and related methods and propagated it into Execute(caller).
• Removed the old expectedToFail argument from WaitForExit, now relying on default behavior.
• Cleaned up test-only behavior scoping by ignoring the disposable scope instead of disposing it.

Reviewed Changes

Copilot reviewed 25 out of 25 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
FrameworkResolution/RollForwardPreReleaseOnly.cs	Added caller param to RunTest overload and pass into call.
FrameworkResolution/RollForwardOnNoCandidateFxSettings.cs	Updated RunTest overload to accept caller and forward it.
FrameworkResolution/RollForwardOnNoCandidateFxMultipleFrameworks.cs	Added caller param to RunTest and propagated to base call.
FrameworkResolution/RollForwardOnNoCandidateFx.cs	Introduced caller param on RunTestWithOneFramework and others.
FrameworkResolution/RollForwardMultipleFrameworks.cs	Added caller to RunTest signature and forwarding.
FrameworkResolution/RollForwardAndRollForwardOnNoCandidateFxSettings.cs	Updated RunTest overload to include caller.
FrameworkResolution/MultipleHives.cs	Added caller param to RunTest overloads; removed disposal of test-only behavior scope.
FrameworkResolution/IncludedFrameworksSettings.cs	Introduced caller parameter on test helpers.
FrameworkResolution/FxVersionCLI.cs	Added caller param to RunTest helper.
FrameworkResolution/FrameworkResolutionBase.cs	Changed .Execute() to .Execute(caller) and added caller to methods.
FrameworkResolution/ComplexHierarchies.cs	Extended RunTest with caller and passed it to base.
FrameworkResolution/ApplyPatchesSettings.cs	Added [CallerMemberName] string caller to RunTest.
FrameworkDependentAppLaunch.cs	Updated .Execute() to .Execute(expectedToFail: true) and removed the boolean overload from WaitForExit.
DependencyResolution/RidAssetResolution.cs	Added caller param to abstract and override RunTest methods.
DependencyResolution/PerAssemblyVersionResolutionMultipleFrameworks.cs	Updated RunTest signatures to include caller.
DependencyResolution/PerAssemblyVersionResolution.cs	Added caller to abstract and override RunTest helpers.
DependencyResolution/ComponentSharedTestStateBase.cs	Extended RunComponentResolutionTest and multithreaded variants to accept caller.
AppHost.Bundle.Tests/BundleRename.cs	Changed WaitForExit(expectedToFail: false, ...) to WaitForExit(...).
AppHost.Bundle.Tests/AppLaunch.cs	Removed boolean arg from WaitForExit(true) to use default WaitForExit().

Comments suppressed due to low confidence (2)

src/installer/tests/HostActivation.Tests/FrameworkResolution/FxVersionCLI.cs:113

• [nitpick] The parameter name 'caller' is a bit ambiguous; consider renaming it to 'callerName' to clearly indicate it holds the calling test method's name.

private CommandResult RunTest(TestSettings testSettings, [CallerMemberName] string caller = "") =>

src/installer/tests/HostActivation.Tests/FrameworkResolution/MultipleHives.cs:277

• By discarding the IDisposable returned by TestOnlyProductBehavior.Enable, the test-only behavior remains enabled for the entire test run and may leak into other tests. Consider retaining and disposing the scope in Dispose to limit its duration.

// Enable test-only behaviour. We don't bother disabling the behaviour later,

[AaronRobinsonMSFT]

Can we remove multiLevelLookup at this point?

[elinor-fung]

Not entirely. For framework resolution, it can still be used for tfm < 7.0 - for example, component using roll-forward. We can probably pare it down a bit and there's definitely things I'd like to clean up here (but in some separate change).