What's expected to work?

[mjtorn]

I gave this a shot because most of the internet seems to have trouble getting anything from UnityEngine working with omnisharp/neovim.

Good stuff, even though I don't have npm, and thus missing out on some of the other goodness.

But UnityEngine just won't autocomplete. No node is required for that, yes?

I even tried 2020.3 from the archives.

Is this still expected to be usable or abandoned or what's up?

[walcht]

Hi, for me I have all features (including LSP, go-to definitions, etc.) except debugging support (unfortunately I have no idea how to implement it with Unity).

No, Node is not required for that.

I have noticed that important pictures in the README file are not shown. These essentially describe an important step to get auto-completion to work. I have fixed their links and now the README should be more clear. If you haven't followed that section in the README then I advise you to do so since LSP problems are most likely caused by those issues.

But, to be fair, it has been weeks since I tested this configuration from scratch (i.e., remove ~/.config/nvim, neovim and install everything again from scratch). I will try this now and let you know as soon as possible about any issues (most probably in the next 10 hours or so).

Thank you for showing interest in this small project and apologies for the unstable state this repository is in currently, I'll do my best to address all issues 😃.

[walcht]

I have removed Neovim, the configuration, dotnet and mono and reconfigured Neovim to use Omnisharp-mono (notice the -mono part). I have noticed a couple of things (Unity 2020.3.46f1):

1. As omnisharp's documentation states repo here mono >= 6.4.0 needs to be globally installed.
2. Omnisharp startup time became extremely slow (used to be fine for me before re-installation). It also managed to almost eat all my memory.
3. UnityEngine.InputSystem was not correctly imported for some reason.

There is Omnisharp (notice absence of -mono) that uses dotnet instead of mono. I will try to use that instead and also try a newer version of Unity.

[mjtorn]

Thanks for checking this out! I was completely busy all week and now hope to put some effort into this.

To me it sounds like you have the same thing as I, because the C# autocompletion otherwise works, except

UnityEngine.InputSystem was not correctly imported for some reason.

and anything else under there.

Is there a general C# (or mono) reason why the sln -> csproj -> Unity chain would be broken?

[mjtorn]

Some more notes. I think it's documented you must use the Mono builds

Omnisharp startup time became extremely slow (used to be fine for me before re-installation). It also managed to almost eat all my memory.

What's extremely slow in this case?

The project loads in something like 17 seconds.

Having said that, I do think I tried disabling on-demand-loading and had to kill NeoVim after some 40 minutes way back.

I'll try to try again in case it's not finding UnityEngine because I ran out of patience with loading lazily.

PS.

Unsure if https://dzfrias.dev/blog/neovim-unity-setup is still a super-relevant resource, but it says there mono6 was pulled from Brew; this is same-enough with my Debian, as you have to use the global Mono install.

OmniSharp-Roslyn v1.38.2^@https://github.com/OmniSharp/omnisharp-roslyn/releases/download/v1.38.2/omnisharp-mono.tar.gz installed

With versions such as that or v1.37.17 I just get a ton of "Unnecessary using directive." errors through the diagnostics pipe, and only the System modules work (ie. Unity does not autocomplete)

Perhaps experiment two will be to see if an older version and not on-demand lazy loading would do something smart.

[mjtorn]

I accidentally conducted experiment two; had NeoVim on in the background.

So yeah, it does complain strangely about those unnecessary imports even with v1.38.2, like if I wanted a shorthand for something from System.Linq, Queryable for example would autocomplete correctly, but the import is "unnecessary".

You're right about Unity.InputSystem specifically. I wonder if there's just a csproj reference bad somewhere.

For what it's worth, I'd concentrate on the diagnostics output, like errors from "using", and then start investigating newer OmniSharp versions and if there's something to configure to make them not slow to load.

[mjtorn]

This is going to proceed sporadically and I may be dumping notes here more than what's professional, but I did upgrade OmniSharp for test's sake, v1.39.11, and it actually works against a 2020.3.48f1 project!

It's not crazy fast and it takes an extra while to start autocompleting UnityEngine, which is sort of surprising, running without on-demand loading; one might believe all or nothing is considered loading.

That's a complete dummy project, though.

A real one is on 2021.3.33f1 and it may actually be failing because of space characters in the project name (like we're living in the past!) instead of the unity version. Gotta check that out asap.

[mjtorn]

Not sure it's the space character. What lead me down that path was that there was a weird stderr notification in omnisharp's log, with some garble, so I thought maybe there's a problem starting things up with a space, because otherwise it should work.

I created a new project with underscores in the name instead, 2021.3.33f1, and omnisharp's slow to load the 49 projects in there.

It could be an internal change in Unity that's causing the grief, but just collecting debug logs is sloooooow. And I wouldn't count on finding anything usable there, at least not by me with my limited experience.

The next thing once I get around to it is to use the on-demand loading with this older omnisharp and newer Unity, to see what happens.

[mjtorn]

I went down another rabbit hole. The 2020 version (Assembly-CSharp.proj) has TargetFrameworkVersion v4.7.1 which is completely missing in the 2021 version.

The 2020 version has (grabbed from this post https://stackoverflow.com/questions/66570036/how-to-change-target-net-framework-used-in-unity-2019) API levels ".NET 4.x" and the selected ".NET standard 2.0".

The 2021 version has ".NET standard 2.1" which I believe was the default and ".NET standard" that I tried out.

None of these inserted anything like v4.7.1 in the CSharp-Assembly.proj file, but I'm thinking something like this could be the reason.

[mjtorn]

Something like https://spaceandtim.es/code/nvim_unity_setup/ makes things seem so easy, but even with on-demand loading the best I can get with Unity 2021.3 is a very slow startup for autocompletion and never (or however long I had this running) anything from UnityEngine.

So far to sum up, for just using things, you'd want the older OmniSharp v1.38.2 for diagnostics output and total autocomplete with Unity 2020.

It would be very, very interesting to understand what's up with the later versions.

[mjtorn]

This https://forum.unity.com/threads/unity-future-net-development-status.1092205/ must be very related. Apparently C# 8 is supported but not .NET 8, and OmniSharp is out of sync with their fork of mono or something.

https://forum.unity.com/threads/net-5-support.839890/page-6#post-7029694 should be an interesting read too, though I have to apologize for using this issue as my bookmarks. Not having time to delve into this, but I think it looks like total support won't be possible until Unity is brought up to speed with .NET.

[walcht]

Hi again (really sorry for the late reply).

No, those are really good points to save in the issue, so thank you so much for that.

I will get back to every single one of these notes in detail on the 14th of February. For me here's what I did to make it finally work and provide auto-completion for pretty much everything! (no longer InputSystem import issue (I think I know why it didn't work at first but to prove that I have to compare .csproj files which I currently can't do...)):

1. Rather that using omnisharp-mono (I think this is the omnisharp mono fork, but I still don't quite understand the difference...) I used omnisharp.

2. Installed dotnet version 8.0.101 (I think anything >= 6.0 will be fine).

3. Regenerated csproj files (ughh, README is wrong. For every new file these have to be regenerated, I think... I have to spend more time understanding what these are exactly) See image below, when I create a new file without regenerating csproj files, Unity-related auto-completion does not work:
   

4. And it worked! Well, startup was in the range of 7-16 minutes. But at the end it was working fine!

5. Monitoring LSP startup memory used on a small XR project (using top command) revealed that omnisharp ate my whole 16GBs of ram during startup!. I think this has to do with logs being buffered somewhere because occasionally Nvim complains about it.
   

6. The issue about omnisharp ram consumption is severe with VSCode. Essentially the whole system crashes... (finally, some extremely convincing reason to use Neovim)

7. After startup, memory consumption is no longer an issue.

This is just a small update about how I managed to address the auto-completion issues (well, at least some of them...).

[walcht]

Uniform: For anything below I'm using this: 22.04.1-Ubuntu | Unity 2023.3.17.f1 | Omnisharp v1.39.11 | Mono (supplied through Omnisharp LSP): 6.12.0.200

Ok I'm ready down deep into the rabbit hole and I can't get out, help!

Is there a general C# (or mono) reason why the sln -> csproj -> Unity chain would be broken?

Absolutely no idea why. I have to go through step-by-step. So far I played with a lot of parameters (change Unity version, + change Mono version then sometimes change Omnisharp version...) for me to identify the reason.

Concerning the InputSystem stuff. I created a new Unity project with the default input system (old) and tried auto-completion:

So three things had to be done to fix that: Install Input System package (obvious), Change Unity's input system to to only use the new one and Re-generate .csproj files (extremely important!):

Added FAQ entry for this in main's README.

What's extremely slow in this case?

Minutes. in the range of 7-16 minutes.

Unsure if https://dzfrias.dev/blog/neovim-unity-setup is still a super-relevant resource, but it says there mono6 was pulled from Brew; this is same-enough with my Debian, as you have to use the global Mono install.

For me, I just used latest version of dotnet and omnisharp (through Mason). I just don't have the energy to test specific versions and their dependencies (it is an extreme rabbit hole...)

You're right about Unity.InputSystem specifically. I wonder if there's just a csproj reference bad somewhere.

I think this is solved (see above).

For what it's worth, I'd concentrate on the diagnostics output, like errors from "using", and then start investigating newer OmniSharp versions and if there's something to configure to make them not slow to load.

For me it is extremely slow. Again, not seconds, not one minute but minutes with CPU going 100% and the whole system slowing down. I think that is really important to solve.

I opened a new issue to address it. I think I know the issue (definitely has to do with logs...). I will add sane Omnisharp args defaults to make it as fast as possible.

The 2021 version has ".NET standard 2.1" which I believe was the default and ".NET standard" that I tried out.

None of these inserted anything like v4.7.1 in the CSharp-Assembly.proj file, but I'm thinking something like this could be the reason.

Interesting. I completely forgot that part. I think I will add a table in README to track which versions (Unity, OS, Omnisharp, Mono, installed through LSP?) this Neovim configuration worked on.

So far to sum up, for just using things, you'd want the older OmniSharp v1.38.2 for diagnostics output and total autocomplete with Unity 2020.

So for each Unity version => best associated Omnisharp and also Mono version? We can document this is the table I suggested above. But, wow, interesting findings (you really did go down the rabbit hole) and this is getting a bit complicated. But worth it, I think.

This https://forum.unity.com/threads/unity-future-net-development-status.1092205/ must be very related. Apparently C# 8 is supported but not .NET 8, and OmniSharp is out of sync with their fork of mono or something.

Haven't read these yet... Will probably do so in the next two weeks (again, after the 14th of February).

https://forum.unity.com/threads/net-5-support.839890/page-6#post-7029694 should be an interesting read too, though I have to apologize for using this issue as my bookmarks.

Agree (about it being an interesting read). Again, the references you provided were really helpful! (seriously, see latest commits: I updated some important things thanks to these 'bookmarks'). Thank you!

I will also definitively implement custom editor script to make that button appear. This is a really good reference:
https://github.com/wackoisgod/com.unity.ide.vscode/blob/sdk-style-support/Packages/com.unity.ide.vscode/Editor/VSCodeScriptEditor.cs

Side note: (I program mostly in Python, TypeScript and C++ so my knowledge of C# and especially its ecosystem is, uhmm, rusty to put it lightly)

[walcht]

Update: InputSystem error is still showing for: Unity version: 2020.3.46f1 | Omnisharp v1.39.11 | Mono (supplied through Omnisharp LSP): 6.12.0.200

[mjtorn]

I'm also busy with other things, but I did dig this old setup out of the mothballs.

It's nvim 0.7.2, OmniSharp 1.38.0, and using mono (ie. the bundled mono, it seems). A project with Unity 2021, but as bad luck would have it I don't think it uses the new input system, autocompletes all the way(!)

I had time to narrow it maybe down to using deoplete-lsp, as typing System gives me OS and lsp hits. From there on, it's all lsp in the list, and disabling deoplete on startup makes it all break.

FWIW the system has mono 6.12.0.200 installed on it.

PS.
Because of whatever problems OmniSharp 1.39 has, I don't really see a need to go there, because 1.38 can be used. I think the more interesting thing would be to figure out what deoplete-lsp is/was doing to make things go. I'd say there's something that these other lsp solutions aren't doing right.

No promises on when I can next look into this, sorry :(

[mjtorn]

I did quickly dig out this https://github.com/neovim/nvim-lspconfig/blob/master/lua/lspconfig/server_configurations/csharp_ls.lua which may be important, as deoplete-lsp doesn't seem to "do" much.

Sadly deoplete is considered dead, and Shougo's replacement ddc requires (apparently) a JavaScript runtime, which I think moves it in a direction I don't want my NeoVim config to go.