Description
nethost returns location of 64-bit hostfxr.dll to 32-bit process.
Reproduction Steps
I have a custom native host that uses nethost to locate hostfxr.dll. I'm running into a problem when testing this native host inside of Xunit tests from "dotnet test". "dotnet test" is 64-bit and is setting DOTNET_ROOT to "C:\Program Files\dotnet". This environment variable is propagating all the way to the testhost.exe process. In my test, I'm calling Process.Start so that is also propagating to my 32-bit custom native host. This means that nethost is returning the path to a 64-bit hostfxr.dll for my 32-bit process.
Expected behavior
Ignore DOTNET_ROOT since it is the wrong architecture.
Actual behavior
Trusts DOTNET_ROOT is correct.
Regression?
Yes. The issue seems to be from #53763. Before that change, x86 nethost would never have used DOTNET_ROOT, only DOTNET_ROOT(x86).
Known Workarounds
In my case, I can workaround this by clearing the DOTNET_ROOT environment variable. Presumably a 32-bit apphost would have the same problem, which might be harder to workaround.
Configuration
- .NET 6.0.4
- Win10
- OS x64, app x86
- runtime.win-x86.Microsoft.NETCore.DotNetAppHost, version=6.0.4
Other information
No response
Description
nethost returns location of 64-bit hostfxr.dll to 32-bit process.
Reproduction Steps
I have a custom native host that uses nethost to locate hostfxr.dll. I'm running into a problem when testing this native host inside of Xunit tests from "dotnet test". "dotnet test" is 64-bit and is setting DOTNET_ROOT to "C:\Program Files\dotnet". This environment variable is propagating all the way to the testhost.exe process. In my test, I'm calling
Process.Startso that is also propagating to my 32-bit custom native host. This means that nethost is returning the path to a 64-bit hostfxr.dll for my 32-bit process.Expected behavior
Ignore DOTNET_ROOT since it is the wrong architecture.
Actual behavior
Trusts DOTNET_ROOT is correct.
Regression?
Yes. The issue seems to be from #53763. Before that change, x86 nethost would never have used DOTNET_ROOT, only DOTNET_ROOT(x86).
Known Workarounds
In my case, I can workaround this by clearing the DOTNET_ROOT environment variable. Presumably a 32-bit apphost would have the same problem, which might be harder to workaround.
Configuration
Other information
No response