microsoft
Consider not redistributing testhost.exe and friends on .NET 11+
Per https://github.com/dotnet/sdk/pull/48599#issuecomment-3127415278 we should consider not explicitly copying testhost.exe to the output directories of builds on Windows hosts.
Eh, we have a hack in MSTest that might get broken with this.
https://github.com/microsoft/testfx/blob/8687e54f761bba78da213cd5ff34562dca3f8945/src/Adapter/MSTestAdapter.PlatformServices/Services/MSTestAdapterSettings.cs#L190-L199
I was talking about these here:
For .NET.
We still need to copy testhost*.exe for .net framework, because we don't have other way there to run tests. The hack talks about appdomains - do .net framework only? :)
@nohwnd Thinking again here. With the current setup, people can have just x64 dotnet.exe installed, and they can run their tests under testhost.x86.exe. If we don't ship that, then I assume we will be under dotnet.exe process. But if there is no x86 dotnet.exe is available, and user is requesting to run under x86, we will be broken. Right?
The testhost exes are not self-contained, so they will have to have an x86 installation of .net runtime on their system either way.
Those testhost exes have only 2 purposes:
- make the name of the process easier to "read" (we run in testhost.exe rather than in dotnet.exe
- find different architecture of dotnet using the rules that are built into that native testhost.x86.exe muxer, rather than via the logic that duplicates the muxer logic that searches for the appropriate dotnet.exe in DotnetRuntimeProvider.
they will have to have an x86 installation of .net runtime
But not necessarily having x86 installation of SDK?
Yes, and that is true also today.
You need some dotnet sdk to have vstest.console. And the console will offload work to testhost processes with the selected platform, you can select this platform per project (via RID), so in the most complex case on ARM64 device, you can have some projects running natively as arm64, some as x86 and some as x64. This would require having arm64, x86 and x64 runtimes on the system.
Those testhost processes can start as dotnet.exe, or as testhost.*.exe, depending on what is found.