C# extension fails to find dotnet after downloading it

[amsoedal]

Environment data

dotnet --info output: N/A VS Code version: 1.89.0 C# Extension version: v2.23.15

OmniSharp log

Failed to find dotnet info from path, falling back to acquire runtime via ms-dotnettools.vscode-dotnet-runtime
Error running dotnet --info: Error: Command failed: dotnet --info
'dotnet' is not recognized as an internal or external command,
operable program or batch file.

'dotnet' is not recognized as an internal or external command,
operable program or batch file.

Dotnet path: c:\Users\redacted\AppData\Roaming\Code\User\globalStorage\ms-dotnettools.vscode-dotnet-runtime\.dotnet\8.0.4~x64\dotnet.exe
Activating C# standalone...
waiting for named pipe information from server...
[stdout] {"pipeName":"\\\\.\\pipe\\1d1ad572"}
received named pipe information from server
attempting to connect client to server...
client has connected to server
[Info  - 4:04:15 PM] [Program] Language server initialized
[Info  - 4:04:15 PM] [LanguageServerProjectSystem] Loading c:\Users\redacted\source\repos\samples\basic-spike\parent\MyService.sln...
[Error - 4:04:15 PM] [LanguageServerHost] System.ComponentModel.Win32Exception (2): An error occurred trying to start process 'dotnet.exe' with working directory 'C:\Users\redacted\AppData\Local\Programs\Microsoft VS Code'. The system cannot find the file specified.
   at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start(ProcessStartInfo startInfo)
   at Microsoft.CodeAnalysis.MSBuild.BuildHostProcessManager.GetBuildHostAsync(BuildHostProcessKind buildHostKind, CancellationToken cancellationToken) in /_/src/Workspaces/Core/MSBuild/MSBuild/BuildHostProcessManager.cs:line 93
   at Microsoft.CodeAnalysis.LanguageServer.HostWorkspace.LanguageServerProjectSystem.OpenSolutionAsync(String solutionFilePath) in /_/src/Features/LanguageServer/Microsoft.CodeAnalysis.LanguageServer/HostWorkspace/LanguageServerProjectSystem.cs:line 100
   at Microsoft.CodeAnalysis.LanguageServer.HostWorkspace.LanguageServerProjectSystem.OpenSolutionAsync(String solutionFilePath) in /_/src/Features/LanguageServer/Microsoft.CodeAnalysis.LanguageServer/HostWorkspace/LanguageServerProjectSystem.cs:line 116
   at Microsoft.CommonLanguageServerProtocol.Framework.QueueItem`3.StartRequestAsync(TRequestContext context, IMethodHandler handler, CancellationToken cancellationToken) in /_/src/Features/LanguageServer/Microsoft.CommonLanguageServerProtocol.Framework/QueueItem.cs:line 157

Steps to reproduce

1. Remove dotnet from PATH
2. Activate C# extension
3. Look at output in C# output pane
4. See error

Expected behavior

My team is developing a new VS Code extension and we want to take a dependency on the C# extension to execute dotnet commands on the user's project. I was testing what would happen if a user doesn't have dotnet pre-installed on the machine. I would expect the extension to restore the missing dotnet binary at activation time and continue to function as normal.

Actual behavior

Even though it looks like the extension puts dotnet in the globalStorage\ms-dotnettools.vscode-dotnet-runtime folder, I consistently get the error shown above and am unable to debug my project.

Additional context

N/A

[JoeRobich]

Whereas a .NET Runtime is installed to support running our LSP, having a .NET SDK is needed for building/loading user projects.

We need to handle this scenario better and to provide an actionable error message to the user.

[dibarbet]

Adding on to this

I would expect the extension to restore the missing dotnet binary at activation time and continue to function as normal.

We do not plan on supporting SDK installation from within C# extension. Choosing, finding, and installing the right SDK isn't necessarily straightforward, and not something we want to manage on the extension side.

Recent versions of the .NET Install Tool extension have added an entry point to install an SDK from within VSCode, however it still requires going through a separate installer (and potentially elevation). A similar entrypoint also exists in C# Dev Kit.

Leaving this issue open though, since as @JoeRobich mentioned we should provide a better error message when an SDK is not present.