Enable test timeout dump collection

[marcpopMSFT]

I do not know the history on why we launch our tests with dotnet-exec. We may hae to change the arguments to match the above commands that we use on netfx (and simplify to just use one).

I'm starting with this just to see if it'll work.

Also open question is where will the dump end up.

[marcpopMSFT]

This doesn't appear to work on non-windows:
The test source file "/private/tmp/helix/working/AB8E0979/w/B5F809E7/e/trx" provided was not found.

And any test that requires msbuildforwardingapp doesn't appear to work correctly within the dotnet test execution.

Applying a fix for the path variable as it was adding quotes that weren't meant to be there.

[marcpopMSFT]

@dsplaisted some of the other failures doing this are because we end up getting the host from the environment but that's now testhost.exe: https://github.com/dotnet/sdk/blob/main/src/Cli/Microsoft.DotNet.Cli.Utils/ForwardingAppImplementation.cs#L99

Is there a better way to find dotnet.exe that we already have in our test infrastructure?

[am11]

illink (and few other tools in runtime repo) finds it via DOTNET_HOST_PATH https://github.com/dotnet/runtime/blob/eee9fd32dbf29d4df263c940b394a8af47bd5cf5/src/tools/illink/src/ILLink.Tasks/LinkTask.cs#L235

[marcpopMSFT]

/azp run dotnet-sdk-public-ci,sdk-source-build,sdk-unified-build

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[marcpopMSFT]

will keep rerunning tests here to see if we can reproduce the arm64 macos test timeout while also looking for a solutino to the path problem. Using an env variable as suggested might work but I was looking for a standard option.

[marcpopMSFT]

@dsplaisted let's chat on Monday about this. I got it working but in two places I had to change product code to fall back to env variables to find the dotnet host when not running. Not sure if we feel comfortable with that and would rather target 9.0.2xx since it's technically customer impacting now though I'm not sure how those scenarios would have worked before if they were returning the testhost.

[am11]

@marcpopMSFT I think reliability-wise, this is the correct order. Note: DOTNET_HOST_PATH holds the absolute path to executable (unlike DOTNET_ROOT which points to directory)

[marcpopMSFT]

BTW, I checked the test results and locally and it looks like using dotnet test with xunit in helix will report the test work item as an additional failure. This was old behavior we used to have for the dotnet exec method of launching tests which we didn't like as it double counted failures and made the AzDO UI less user friendly.

I'm going to ping the test folks to see if there is an option for this.

[marcpopMSFT]

unrelated failure in Microsoft.DotNet.Watcher.Tools.FileWatcherTests.DeleteSubfolder. Rerrunning all to see if that resolves it or else I'll ping the watch team next. Don't see the failure in other PRs that I've poked at.