Error on ARM64 Windows 11 when executing dotnet.exe

[christophwille]

This test https://github.com/icsharpcode/ILSpy/blob/master/ICSharpCode.Decompiler.Tests/CorrectnessTestRunner.cs#L38 calls the underlying dotnet.exe compilation that is wrapped with CliWrap https://github.com/icsharpcode/ILSpy/blob/master/ICSharpCode.Decompiler.Tests/Helpers/Tester.cs#L135. That has worked and still is working great on x64.

On ARM64 I get the following:

 AllFilesHaveTests
   Source: CorrectnessTestRunner.cs line 38
   Duration: 25.8 sec

  Message: 
OneTimeSetUp: CliWrap.Exceptions.CommandExecutionException : Command execution failed because the underlying process (dotnet.exe#52568) returned a non-zero exit code (-2147450735).

Command:
dotnet.exe build Z:\GitWorkspace\ILSpy\ICSharpCode.Decompiler.Tests\bin\Debug\net8.0-windows\win-x64\../../../../../ICSharpCode.Decompiler.TestRunner/ICSharpCode.Decompiler.TestRunner.csproj -r win-x86 -c Debug --self-contained

You can suppress this validation by calling `WithValidation(CommandResultValidation.None)` on the command.

  Stack Trace: 
Command.ExecuteAsync(ProcessEx process, CancellationToken forcefulCancellationToken, CancellationToken gracefulCancellationToken) line 271
Command.ExecuteAsync(ProcessEx process, CancellationToken forcefulCancellationToken, CancellationToken gracefulCancellationToken) line 287
Command.ExecuteAsync(ProcessEx process, CancellationToken forcefulCancellationToken, CancellationToken gracefulCancellationToken) line 287
Command.ExecuteAsync(ProcessEx process, CancellationToken forcefulCancellationToken, CancellationToken gracefulCancellationToken) line 287
Tester.BuildTestRunner(String runtime, String config) line 145
Tester.Initialize() line 136
ToolsetSetup.RunBeforeAnyTests() line 55
GenericAdapter`1.BlockUntilCompleted()
NoMessagePumpStrategy.WaitForCompletion(AwaitAdapter awaiter)
AsyncToSyncAdapter.Await[TResult](Func`1 invoke)
AsyncToSyncAdapter.Await(Func`1 invoke)
SetUpTearDownItem.RunSetUpOrTearDownMethod(TestExecutionContext context, IMethodInfo method)
SetUpTearDownItem.RunSetUp(TestExecutionContext context)
<.ctor>b__0(TestExecutionContext context)
BeforeTestCommand.Execute(TestExecutionContext context)
BeforeTestCommand.Execute(TestExecutionContext context)
CompositeWorkItem.PerformOneTimeSetUp()

If I take the command and paste it in Terminal, even though I build win-x86, it runs just fine with no complaints whatsover. CliWrap is latest, .NET 8.0 latest from yesterday's Patch Tuesday, same for VS. Any ideas (and possibly how to debug?)?

[Tyrrrz]

Try running it with ExecuteBufferedAsync() to capture the stderr in the error message

[christophwille]

It still throws with ExecuteBufferedAsync (and thus result = is null), but the exception text in the VS debugger is more helpful:

Command execution failed, see the inner exception for details.

Standard error:
The command could not be loaded, possibly because:
  * You intended to execute a .NET application:
      The application 'build' does not exist.
  * You intended to execute a .NET SDK command:
      A compatible .NET SDK was not found.

Requested SDK version: 8.0.100
global.json file: Z:\GitWorkspace\ILSpy\global.json

Installed SDKs:
No .NET SDKs were found.

Install the [8.0.100] .NET SDK or update [Z:\GitWorkspace\ILSpy\global.json] to match an installed SDK.

Download a .NET SDK:
https://aka.ms/dotnet/download

Learn about SDK resolution:
https://aka.ms/dotnet/sdk-not-found

The global.json

{
  "sdk": {
    "version": "8.0.100",
    "rollForward": "major",
    "allowPrerelease": true
  }
} 

I am racking my mind why that would behave that way... setting to .303 doesn't help. PS as well as command both execute dotnet.exe nicely, so those two find dotnet correctly. Q then is why the non-interactive variation with CliWrap fails... almost looks like PATH isn't picked up.

[Tyrrrz]

but the exception text in the VS debugger is more helpful:

Yeah that was the goal. It captures stderr so shows more info in the error message.

[christophwille]

Right, await Cli.Wrap("c:\\program files\\dotnet\\dotnet.exe") instead of await Cli.Wrap("dotnet.exe") works. But why would an interactive prompt properly pick up the system env var PATH and CliWrap wouldn't (on ARM64 compared to x64)?

[christophwille]

Environment.GetEnvironmentVariable("PATH") however contains the expected env var (in my code before the CliWrap call, which should be good enough). Is there any custom path logic inside CliWrap?

[Tyrrrz]

Is there any custom path logic inside CliWrap?

Yes, but for exe files it should be the same as the system resolution logic.

CliWrap/CliWrap/Command.Execution.cs

Lines 17 to 71 in 9e4e6bf

	// System.Diagnostics.Process already resolves the full path by itself, but it naively assumes that the file
	// is an executable if the extension is omitted. On Windows, BAT and CMD files may also be valid targets.
	// In practice, it means that Process.Start("foo") will work if it's an EXE file, but will fail if it's a
	// BAT or CMD file, even if it's on the PATH. If the extension is specified, it will work in both cases.
	private string GetOptimallyQualifiedTargetFilePath()
	{
	// Currently, we only need this workaround for script files on Windows, so short-circuit
	// if we are on a different platform.
	if (!RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
	return TargetFilePath;
	// Don't do anything for fully qualified paths or paths that already have an extension specified.
	// System.Diagnostics.Process knows how to handle those without our help.
	// Note that IsPathRooted(...) doesn't check if the path is absolute, as it also returns true for
	// strings like 'c:foo.txt' (which is relative to the current directory on drive C), but it's good
	// enough for our purposes and the alternative is only available on .NET Standard 2.1+.
	if (
	Path.IsPathRooted(TargetFilePath)
	|| !string.IsNullOrWhiteSpace(Path.GetExtension(TargetFilePath))
	)
	return TargetFilePath;
	static IEnumerable<string> GetProbeDirectoryPaths()
	{
	// Implementation reference:
	// https://github.com/dotnet/runtime/blob/9a50493f9f1125fda5e2212b9d6718bc7cdbc5c0/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs#L686-L728
	// MIT License, .NET Foundation
	// Executable directory
	if (!string.IsNullOrWhiteSpace(EnvironmentEx.ProcessPath))
	{
	var processDirPath = Path.GetDirectoryName(EnvironmentEx.ProcessPath);
	if (!string.IsNullOrWhiteSpace(processDirPath))
	yield return processDirPath;
	}
	// Working directory
	yield return Directory.GetCurrentDirectory();
	// Directories on the PATH
	if (Environment.GetEnvironmentVariable("PATH")?.Split(Path.PathSeparator) is { } paths)
	{
	foreach (var path in paths)
	yield return path;
	}
	}
	return (
	from probeDirPath in GetProbeDirectoryPaths()
	where Directory.Exists(probeDirPath)
	select Path.Combine(probeDirPath, TargetFilePath) into baseFilePath
	from extension in new[] { "exe", "cmd", "bat" }
	select Path.ChangeExtension(baseFilePath, extension)
	).FirstOrDefault(File.Exists) ?? TargetFilePath;
	}

[christophwille]

I let that error message simmer a little bit - and then it dawned on me: there is an x64 RID on that test project, and thus it was starting the CLI in that process mode as well, and of course there is no x64 net8.0 SDK on that machine, only the ARM64 version. Setting

<RuntimeIdentifier>win-arm64</RuntimeIdentifier>

made the unmodified code work right away. Although I am still surprised that the prior full-path-variant worked....

[Tyrrrz]

I know some environment variables may have different values if you run an app in emulation, such as x86 on x64 or x64 on arm64, etc. But if you checked PATH and it's right, then I'm not sure exactly what causes it. Maybe the .NET Host Resolver detects the target architecture somehow and resolves to an x64-based runtime.