Improve behaviour of .NET version detection when the .NET host cannot resolve a matching runtime or SDK for global.json.
The dotnet host has many known exit codes, but currently only a couple are currently of interest to us. I have nevertheless included all known exit codes in an enum since the exit-code names (rather than just hex numbers) are quite likely to aid future troubleshooting efforts.,
This PR only partially addresses tintoy/msbuild-project-tools-vscode#156 (the language server side), although, since VSCode's language client doesn't provide access to the process exit code, it's challenging (for the extension side) to reliably return user-facing error messages from the language server (in scenarios like this that occur before the LSP connection has been established).
We might want to consider changing our STDERR output, at some point, be JSON format so the extension has a better chance of interpreting it.
Improve behaviour of .NET version detection when the .NET host cannot resolve a matching runtime or SDK for
global.json
.The
dotnet
host has many known exit codes, but currently only a couple are currently of interest to us. I have nevertheless included all known exit codes in an enum since the exit-code names (rather than just hex numbers) are quite likely to aid future troubleshooting efforts.,This PR only partially addresses tintoy/msbuild-project-tools-vscode#156 (the language server side), although, since VSCode's language client doesn't provide access to the process exit code, it's challenging (for the extension side) to reliably return user-facing error messages from the language server (in scenarios like this that occur before the LSP connection has been established).
We might want to consider changing our STDERR output, at some point, be JSON format so the extension has a better chance of interpreting it.