Failed to load Project with no error message about omnisharp-vim HOT 18 OPEN

Have you looked in the log? :OmniSharpOpenLog

from omnisharp-vim.

Ahhh, there we go. Knew I was missing something obvious.

[fail]: OmniSharp.MSBuild.ProjectLoader
        The reference assemblies for ".NETFramework,Version=v7.0" were not found. You might be using an older .NET SDK to target .NET 5.0 or higher. Update Visual Studio and/or your .NET SDK.

Now I have an error to work with at least.

$dotnet --version
7.0.101

I clearly have dotnet 7.

$dotnet --list-sdks
3.1.301 [/usr/local/share/dotnet/sdk]
5.0.101 [/usr/local/share/dotnet/sdk]
5.0.303 [/usr/local/share/dotnet/sdk]
6.0.101 [/usr/local/share/dotnet/sdk]
7.0.101 [/usr/local/share/dotnet/sdk]

I also seem to have a lot of sdks installed.. wonder if it's getting confused or something

from omnisharp-vim.

What OmniSharp-vim config do you have? This is a dotnet project (not Framework) so I think you'll need to be using the net6 build of omnisharp-roslyn. Do you have let g:OmniSharp_server_use_net6 = 1 in your config?

from omnisharp-vim.

The only configs I have set up for Omnisharp-vim are:

let g:OmniSharp_start_server = 0

I tried setting the SDK and useModernNet in ~/.config/.omnisharp/omnisharp.json, but I'll remove those unless you suggest I try them.

I'll try let g:OmniSharp_server_use_net6 = 1

from omnisharp-vim.

After setting let g:OmniSharp_server_use_net6 = 1 you'll need to reinstall the server, :OmniSharpInstall. That downloads a different server build of omnisharp-roslyn.

from omnisharp-vim.

By the way,

I tried setting the SDK and useModernNet in ~/.config/.omnisharp/omnisharp.json, but I'll remove those unless you suggest I try them.

The default path for system-wide omnisharp.json is ~/.omnisharp/omnisharp.json, it's not under ~/.config unluess you configured it with an OMNISHARPHOME environment variable

from omnisharp-vim.

Well then I guess it didn't make any difference, haha.

It does seem to be loading now!
The 180s timeout triggers, so I imagine the sheer number of .csproj files is just taking too long.
Could that cause any issues?

I used the bindings suggested in the Wiki, but is there an easy way to use CoC to handle the goto-def, find uses, etc.?

Thanks for the help, I appreciate it

from omnisharp-vim.

Also, is there any way to start the server in the background so I don't have to wait a couple of minutes every time I want to work on the project? Or do I have a misguided idea of how it works

from omnisharp-vim.

Also, is there any way to start the server in the background so I don't have to wait a couple of minutes every time I want to work on the project? Or do I have a misguided idea of how it works

You have specifically stopped the server from loading automatically with let g:OmniSharp_server_use_net6 = 1. Or am i misunderstanding you?

from omnisharp-vim.

Can you share a log please? I don't think it's working correctly yet - have you re-installed the server?

from omnisharp-vim.

Also, is there any way to start the server in the background so I don't have to wait a couple of minutes every time I want to work on the project? Or do I have a misguided idea of how it works

You have specifically stopped the server from loading automatically with let g:OmniSharp_server_use_net6 = 1. Or am i misunderstanding you?

Yes, I'm good with that. But when I do manually start the server, it takes about 2 minutes to load all of the csproj files.

So my question is; is there a way to start the server outside of vim and leave it running, so when I open vim the server is already running and ready to go, no csproj loading required.

All of the bindings are working as expected, so I think things are looking pretty good. If I can get closer CoC integration I'll be very happy

from omnisharp-vim.

No vim can't interact with an external process that it hasn't started itself, so the only way to run language servers is for vim to start them and handle all of the input/output.

I don't really know what you mean by coc integration. Coc uses certain bindings for go-to-definition, find-usages etc. - just override those same bindings in .cs buffers.

from omnisharp-vim.

Ah, makes sense.

Maybe I could use the HTTP interaction instead? Could I do the whole background thing in that setup?

Good idea on the rebinds, simple and easy 👍

from omnisharp-vim.

What you are describing is basically the only benefit to the HTTP version of the server, over stdio - yes it worked independently of vim that way.

Unfortunately that integration was also very limited and so is extremely light on features. The HTTP integration used python and hasn't been developed in several years. There is syntax highlighting but it's not highly accurate, there is no test runner, the log is much more basic. Essentially ... I don't recommend it.

If I were you I'd create personal .sln files to deal with the project or projects you are using. That is a matter of a few seconds:

dotnet new sln -n MyTempSolution
dotnet sln MyTempSolution.sln add Proj1.csproj
dotnet sln MyTempSolution.sln add Proj2.csproj

from omnisharp-vim.

That's a pretty good idea. Not ideal, but it's a fair compromise.

For projects that I don't add, will they be essentially invisible to find-usages, etc.?

from omnisharp-vim.

For projects that I don't add, will they be essentially invisible to find-usages, etc.?

Yes.

That's a pretty good idea. Not ideal, but it's a fair compromise.

You must have come across similar speed issues in VS/Rider with a 120-project solution?

The nice thing is that vim is really good at search, especially configuring 'grepprg' to something like ripgrep or ag. I work on an even bigger repo, just under 200 projects, but we have it broken into a bunch of solutions. I can grep the entire repo in milliseconds and then as soon as I open a result omnisharp-vim just starts a server for that solution if it's not already running.

Its' a pretty standard trade-off between the convenience of having the language server looking at the entire code-base, and the speed of just running in part of it. I'm not suggesting you change your entire org, but having a few personal .sln files around just makes things much faster.

from omnisharp-vim.

Yes.

Fair enough

You must have come across similar speed issues in VS/Rider with a 120-project solution?

Oh yeah, definitely. It's even longer probably because of all of the other processes/tools that run in the background. The difference for me is I can easily leave Rider running all day, so the speed problem is only inconvenient when I checkout a different branch (and, of course, on startup)

I can grep the entire repo in milliseconds and then as soon as I open a result omnisharp-vim just starts a server for that solution if it's not already running.
Interesting! I didn't even put that together; that makes a lot of sense.

Do you ever run into issues with Shared structs/classes that are used between/amongst multiple solutions? Type converters, error handlers, etc. or do you add a lot of the shared stuff into each of your personal solution files? (or perhaps more broadly, if you know that project X and Y have a tight correlation, would your personal files load both X and Y when you open either?)

One more question: I found that when loading everything, goto definition, find references, etc. is fairly slow. Maybe 2-5 seconds sometimes. Is that problem reduced when you limit how many projects are loaded?

from omnisharp-vim.

Oh yeah, definitely. It's even longer probably because of all of the other processes/tools that run in the background.

This is actually how I started using vim 😄. I had a really slow machine at one point and used to use vim for fast edits while I was waiting for VS to become usable.

The difference for me is I can easily leave Rider running all day

You don't do this with vim?

do you add a lot of the shared stuff into each of your personal solution files?

I don't actually use personal solution files very often, because our repo is structured with lots of smaller solutions anyway. But ...

Do you ever run into issues with Shared structs/classes that are used between/amongst multiple solutions?

... yes this can be an issue. When you modify an interface or struct at a lower level, then you may well need to restart the higher-level servers, with :OmniSharpRestartServer or a mapping (vim-sharpenup creates default mapping \osre for this). This can be a nuisance but only takes a few seconds with small solutions. The nice thing is that omnisharp-vim is quite happy to run lots of servers in a single vim session. If you run :OmniSharpStatus you can see which servers are running:

/data/code/rs/libraries/[Solution1]/[Solution1].sln
  pid: 328877
  running (1 project) for 17 minutes
/data/code/rs/libraries/[Solution2]/[Solution2].sln
  pid: 288261
  running (2 projects) for an hour and 31 minutes
/data/code/rs/libraries/[Solution3]/[Solution3].sln
  pid: 287782
  running (1 project) for an hour and 31 minutes
/data/code/rs/tools/[TooBigSolution].sln
  pid: 221401
  running (31 projects) for 20 hours

So after modifying something in [Solution1] I may need to restart the others, which is no issue for [Solution2] and [Solution3] but is annoying in [TooBigSolution] with 31 projects - I do actually use personal solutions to break up [TooBigSolution] sometimes.

would your personal files load both X and Y when you open either?

You can do that, although if you have 2 servers running simultaneously where they both include X, then modifying X in one won't be reflected in the other until you restart it.

One more question: I found that when loading everything, goto definition, find references, etc. is fairly slow. Maybe 2-5 seconds sometimes. Is that problem reduced when you limit how many projects are loaded?

I expect so. I never work in a solution as big as yours but go-to-definition and find-usages never take longer than half a second, unless the server is still warming up. I just tried in [TooBigSolution] and find-implementations took maybe a second on an interface with 137 implementations the first time, maybe quarter of a second after that.

from omnisharp-vim.