can not run csharp lsp if net 9 installed even i installed net8，Please allow rollforword #7925
Comments
heartacker
changed the title
|
I suspect there is something wrong with your .NET installation. We do enable I tested this myself with only a .NET 9 installation and everything seems to work as expected In your |
|
i set dotnetAcquisitionExtension.existingDotnetPath in my config, But that shouldn't be a problem, right? |
|
I'm having the exact same issue with the same version of the lsp extension. I went back one version to 2.55.29 and it works fine. It is either a bug with this version or a breaking change. |
A couple things
It seems like something is pointing the extension to a path that doesn't have a completely valid .NET |
In my case PS: My dotnet info |
|
Thanks for the info!
So I think you shouldn't necessarily need to even need to have However - @nagilson should the runtime extension be returning the real path if |
|
I can confirm that the issue occurs when Changing it to the actual binary solves the problem. |
|
It currently returns the symlink, but it does verify if the PATH meets the conditions of the API request, however, by scanning the runtime and SDK by trying to call the symlink as an executable @dibarbet How does the server host fail if calling dotnet on the host path has the runtime and sdk that's on the request? (Presumably.) It would be good to collect a log from us from the user too if the answer to that isn't immediately obvious. Maybe this wasn't as noticeable as we also do the --list-runtimes logic on the PATH to go 2 directories up for the PATH but we dont do that on the user setting, which might be the better way to solve this. |
To clarify - it looks like the server is failing because we're trying to find the DOTNET_ROOT from the executable path you give back to us. When the option points to a symlink, the executable path we get is the symlink path. Then because
To me it seems like the symlink should be resolved before we get the executable path? Open to ideas though. We could also resolve it, but seems possibly not ideal since we don't own the option. |
Snap (after installing via package manager and uninstalling, then using snap)Interesting, the symlink which could be set as /usr/lib/dotnet in this case doesn't work as an executable with snap when we try to find the executable due to how its placed (/usr/lib/dotnet/dotnet does not exist.) But our code uses custom snap logic to make it work in a different method. Package ManagerHowever with a package manager, /usr/lib/dotnet is the actual location and /usr/lib/dotnet/dotnet is a valid executable, so this works. /usr/bin/dotnet is also a valid executable, and that is the symlink to the lib folder, so our logic accepts it, but then it's not valid for DOTNET_ROOT. I didnt know DOTNET_ROOT required the folder, so thank you for that context @dibarbet. Our path logic tries to not do realpath first, and this would normally have been caught so we'd give the correct path; its OK because we call --list-runtimes and go 2 directories up. But we didn't do that for the user setting path in an attempt to respect what they set. SolutionThis should be fixed in our extension. This means we could both would cause us to return path.join(/usr/lib/dotnet, dotnet), however, realpath already returns the executable, while list--runtimes parsing would point us only to /usr/lib/dotnet/shared/blah. a and b have similar ish performance characteristics because they both need to spawn a shell (most expensive perf), but --list-runtimes is going to be cached in the future so that theoretically means list-runtimes is faster as it wont need to spawn a shell. I guess we could cache realpath too, so performance isnt much of a concern. b is better in my opinion, as a would actually break with a snap install. realpath of snap/bin/dotnet is /usr/bin/snap, which is not a valid executable, so it wouldn't be found. since it follows the flow of the other code in our extension to go 2 dirs up at the end of the call. Users do some (wild) stuff and if they removed realpath from their system we'd also be cooked in that situation, not that its a high priority. |
|
I'll make a PR to fix this. Thank you for reporting and I'm sorry for this inconvenience. |
For dotnet/vscode-csharp#7925 (comment) We have a custom setting and could cause C# to fail if someone sets the setting to a symlink install which doesn't actually have a folder in it, even if it has a valid executable because DOTNET_ROOT wants a folder. Read more below on how this fix works and why. # Snap (after installing via package manager and uninstalling, then using snap) Interesting, the symlink which could be set as /usr/lib/dotnet in this case doesn't work as an executable with snap when we try to find the executable due to how its placed (/usr/lib/dotnet/dotnet does not exist.) But our code uses custom snap logic to make it work in a different method. # Package Manager However with a package manager, /usr/lib/dotnet is the actual location and /usr/lib/dotnet/dotnet is a valid executable, so this works. /usr/bin/dotnet is also a valid executable, and that is the symlink to the lib folder, so our logic accepts it, but then it's not valid for DOTNET_ROOT. I didnt know DOTNET_ROOT required the folder, so thank you for that context @dibarbet. Our path logic tries to not do realpath first, and this would normally have been caught so we'd give the correct path; its OK because we call --list-runtimes and go 2 directories up. But we didn't do that for the user setting path in an attempt to respect what they set. # Solution This should be fixed in our extension. I dont know if I'd call it a 'bug' per se, but we can make the behavior better. They shouldnt have to know all of this nuance. This means we could a - call realpath on /usr/bin/dotnet (or the user setting) b - call --list-runtimes on /usr/bin/dotnet (the user setting) and go 2 directories up to find the actual path both would cause us to return path.join(/usr/lib/dotnet, dotnet), however, realpath already returns the executable, while list--runtimes parsing would point us only to /usr/lib/dotnet/shared/blah. a and b have similar ish performance characteristics because they both need to spawn a shell (most expensive perf), but --list-runtimes is going to be cached in the future so that theoretically means list-runtimes is faster as it wont need to spawn a shell. I guess we could cache realpath too, so performance isnt much of a concern. b is better in my opinion, as a would actually break with a snap install. realpath of snap/bin/dotnet is /usr/bin/snap, which is not a valid executable, so it wouldn't be found. since it follows the flow of the other code in our extension to go 2 dirs up at the end of the call. Users do some (wild) stuff and if they removed realpath from their system we'd also be cooked in that situation, not that its a high priority.
* Permit Invalid Symlink Folders to Work as Custom Path Setting For dotnet/vscode-csharp#7925 (comment) We have a custom setting and could cause C# to fail if someone sets the setting to a symlink install which doesn't actually have a folder in it, even if it has a valid executable because DOTNET_ROOT wants a folder. Read more below on how this fix works and why. # Snap (after installing via package manager and uninstalling, then using snap) Interesting, the symlink which could be set as /usr/lib/dotnet in this case doesn't work as an executable with snap when we try to find the executable due to how its placed (/usr/lib/dotnet/dotnet does not exist.) But our code uses custom snap logic to make it work in a different method. # Package Manager However with a package manager, /usr/lib/dotnet is the actual location and /usr/lib/dotnet/dotnet is a valid executable, so this works. /usr/bin/dotnet is also a valid executable, and that is the symlink to the lib folder, so our logic accepts it, but then it's not valid for DOTNET_ROOT. I didnt know DOTNET_ROOT required the folder, so thank you for that context @dibarbet. Our path logic tries to not do realpath first, and this would normally have been caught so we'd give the correct path; its OK because we call --list-runtimes and go 2 directories up. But we didn't do that for the user setting path in an attempt to respect what they set. # Solution This should be fixed in our extension. I dont know if I'd call it a 'bug' per se, but we can make the behavior better. They shouldnt have to know all of this nuance. This means we could a - call realpath on /usr/bin/dotnet (or the user setting) b - call --list-runtimes on /usr/bin/dotnet (the user setting) and go 2 directories up to find the actual path both would cause us to return path.join(/usr/lib/dotnet, dotnet), however, realpath already returns the executable, while list--runtimes parsing would point us only to /usr/lib/dotnet/shared/blah. a and b have similar ish performance characteristics because they both need to spawn a shell (most expensive perf), but --list-runtimes is going to be cached in the future so that theoretically means list-runtimes is faster as it wont need to spawn a shell. I guess we could cache realpath too, so performance isnt much of a concern. b is better in my opinion, as a would actually break with a snap install. realpath of snap/bin/dotnet is /usr/bin/snap, which is not a valid executable, so it wouldn't be found. since it follows the flow of the other code in our extension to go 2 dirs up at the end of the call. Users do some (wild) stuff and if they removed realpath from their system we'd also be cooked in that situation, not that its a high priority. * Try to get the existing path * Only call real path if allow invalid path is false * Fix the test * Improve test logic
|
closing this issue. there is a fix on the way (in the vscode dotnet runtime extension) and available workarounds |
|
I'm using Code OSS because it came with my distro and it was showing the same error message about: "Microsoft.CodeAnalysis.LanguageServer client: couldn't create a connection to server", but after I installed code-marketplace to enable vscode marketplace in Code OSS, I could install it, and it worked fine now. |
Environment data
dotnet --infooutput:VS Code version:
C# Extension version:
OmniSharp log
Steps to reproduce
install net 9 and no net 8
Expected behavior
work well
Actual behavior
Additional context
please allow language server runing net 9 and above within --allow-roll-forward
see https://learn.microsoft.com/zh-cn/dotnet/core/tools/dotnet#rollforward
The text was updated successfully, but these errors were encountered: