Closed rcmosher closed 2 years ago
This is a server issue. There's a PR for a fix in place here: https://github.com/OmniSharp/omnisharp-roslyn/pull/2443
I installed omnisharp-roslyn v1.39.2-beta.10 (using a modified omnisharp-manager.sh) and I'm still getting the same errors. I'll do a little more digging and post in the omnisharp-roslyn project. But it looks like the latest beta doesn't fix this.
I tried a few things to resolve this after the above. I updated Visual Studio 2022 which did not resolve the issue. Then I ran :OmniSharpInstall from gVim in Windows instead of WSL and it started working. I'm a little surprised OmniSharp in WSL knew to use the Windows install since WSL installed to omnisharp-rosly and Windows to omnisharp-roslyn.
Looking at logs in ~/vimfiles/plugged/omnisharp-vim/log/ there's some obvious differences in what is being referenced. When working it's referencing .Net Core SDK, and when broken it's referencing Visual Studio. Also surprising is the Windows version change from 6.2.9200.0 to 10.0.19044.0. Not sure what that version means but I did not upgrade Windows. LOL.
Broken Log
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled May 10 2022 08:40:37), Included patches: 1-105
OmniSharp server started.
Path: /mnt/c/Users/me/AppData/Local/omnisharp-vim/omnisharp-rosly/OmniSharp.exe
Target: /mnt/c/Development/ScrappyCorp/GloboCorp.Project/src/GloboCorp.Project.sln
PID: 31909
[info]: OmniSharp.Stdio.Host
Starting OmniSharp on Windows 6.2.9200.0 (x64)
[info]: OmniSharp.Services.DotNetCliService
Checking the 'DOTNET_ROOT' environment variable to find a .NET SDK
[info]: OmniSharp.Services.DotNetCliService
Using the 'dotnet' on the PATH.
[info]: OmniSharp.Services.DotNetCliService
DotNetPath set to dotnet
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
Located 2 MSBuild instance(s)
1: Visual Studio Professional 2022 17.3.32819.101 17.3.1 - "C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Current\Bin"
2: Visual Studio Professional 2019 16.11.32002.261 16.11.2 - "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin"
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
Registered MSBuild instance: Visual Studio Professional 2022 17.3.32819.101 17.3.1 - "C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Current\Bin"
Working Log
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled May 10 2022 08:40:37), Included patches: 1-105
OmniSharp server started.
Path: /mnt/c/Users/me/AppData/Local/omnisharp-vim/omnisharp-roslyn/OmniSharp.exe
Target: /mnt/c/Development/ScrappyCorp/GloboCorp.Project/src/GloboCorp.Project.sln
PID: 2583
[info]: OmniSharp.Stdio.Host
Starting OmniSharp on Windows 10.0.19044.0 (x64)
[info]: OmniSharp.Services.DotNetCliService
Checking the 'DOTNET_ROOT' environment variable to find a .NET SDK
[info]: OmniSharp.Services.DotNetCliService
Using the 'dotnet' on the PATH.
[info]: OmniSharp.Services.DotNetCliService
DotNetPath set to dotnet
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
Located 4 MSBuild instance(s)
1: .NET Core SDK 6.0.402 17.3.2 - "C:\Program Files\dotnet\sdk\6.0.402\"
2: .NET Core SDK 6.0.304 17.2.0 - "C:\Program Files\dotnet\sdk\6.0.304\"
3: .NET Core SDK 6.0.109 17.0.0 - "C:\Program Files\dotnet\sdk\6.0.109\"
4: .NET Core SDK 6.0.100 17.0.0 - "C:\Program Files\dotnet\sdk\6.0.100\"
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
Registered MSBuild instance: .NET Core SDK 6.0.402 17.3.2 - "C:\Program Files\dotnet\sdk\6.0.402\"
It's hard to be sure from the details you've given but it looks like the "broken" version is using the older. NET Framework build of OmniSharp-roslyn, and the "working" version is using the new net6 build.
I did add let g:OmniSharp_server_use_net6 = 1
but I bet since I was doing a manual install of beta I never actually reinstalled, or downloaded the correct zip for net6.
I get the following error for all project files when using omnisharp-vim.
I tried adding
let g:OmniSharp_server_use_net6 = 1
as resolved this similar issue, but it had no effect. Though I wouldn't be surprise if I missed some additional steps needed for WSL.These two issues from other projects seem like they might be related. uno issue 9297 docfx issue 8097
WSL 1 dotnet 6.0.400 omnisharp-roslyn 1.39.1
Logs
full log file