Fix dotnet path resolution when using snap installed packages #6515
Conversation
| if (!existsSync(dotnetExecutablePath)) { | ||
| throw new Error( | ||
| `dotnet executable path does not exist: ${dotnetExecutablePath}, dotnet installation may be corrupt.` | ||
| ); | ||
| } | ||
|
|
||
| this.channel.appendLine(`Using dotnet configured on PATH`); |
There was a problem hiding this comment.
Does this message need to change? Or should it now log the path we created?
There was a problem hiding this comment.
the path will be logged in the caller anway, and we're still using the dotnet from the path, so think this is fine.
| // Therefore we know that the runtime path is always in <install root>/shared/<runtime name> | ||
| // and the dotnet executable is always at <install root>/dotnet(.exe). |
There was a problem hiding this comment.
Should we be renaming this function? (findDotnetFromPath)?
There was a problem hiding this comment.
I think this is still valid - this is still from the dotnet on path (via executing the dotnet commands)
|
So what do I have to do to fix this problem? dotnet --list-runtimes |
This change will most likely be in next weeks release which should resolve the issue. If you want to workaround it for now, I think there are a few options. If you're only using C# (and not C# devkit), you can workaround this issue by setting Alternatively, making sure the Another user also mentioned running this - |
On systems installing dotnet via snap, the dotnet on the path does not point to the dotnet install location, even via symlinks. Instead, it is symlinked to the snap executable, e.g.
/usr/bin/snap.So calling
which dotnetand reading symlinks will not give us a valid dotnet installation.The fix here is to instead parse the output of
dotnet --list-runtimeswhich will return the real assembly locations of the dotnet install. Since the dotnet install has a known layout, we can easily find the dotnet executable given a runtime install path.See #6513 for more info.
Resolves #6513