Imports not detected when client sends only `textDocument/didOpen` on newly created file (Unity project, neovim client)

[mjlbach]

Hi!

I'm trying to troubleshoot some issues the client I work on has with omnisharp-roslyn, and I was hoping I could ping you all for help.

The issue is, when opening a unity project, say one containing the following file:

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class NewBehaviourScript : MonoBehaviour
{
    // Start is called before the first frame update
    void Start()
    {
    }

    // Update is called once per frame
    void Update()
    {
        
    }
}

Everything is fine, our client detects the imports no problem.

However, the minute we open a new file (for which we send the requisite textDocument/didOpen notification) with the exact same content, in the exact same subdirectory, the server returns import error messages:

The type or namespace name 'UnityEngine' could not be found (are you missing a using directive or an assembly reference?) irective or an assembly reference?)

Other servers seem to be fine recognizing new files this way. Do we need to send an additional notification when creating a new file such as workspace/didChangeWatchedFiles?

[ChimpSpin]

Having the same issue in Helix.

[JoeRobich]

Unity projects are Full Framework style projects and require each code file to have a corresponding <Compile Include="{filename}" /> element in the .csproj to be included in the project. If you have added a new file without adding the <Compile> element, then I would expect O# to open the file in its "Miscellaneous" project which does not include any Unity dependencies.

Edit: After reviewing what happens when the FileChangeWatcher fires, there is a heuristic in O# that will match a new code file to an existing project based on whether the code file exists alongside or beneath the project file on the filesystem. This matching would not persist between sessions unless the project file was updated with the appropriate <Compile> element.

[JoeRobich]

However, the minute we open a new file

Is this a new file that has been saved and exists on disk?

Do we need to send an additional notification when creating a new file such as workspace/didChangeWatchedFiles?

If the file was added to the filesystem, then I expect that file watchers would need to be updated.

[mjlbach]

Is this a new file that has been saved and exists on disk?

It's a new file that has not been added to the project. If I'm understanding you correctly then you must regenerate the solution files after the addition of a new file for omnisharp to pick up the imports correctly?

It seems to work fine in vscode creating a new file without regenerating the solution file in unity, no errors are thrown (left).
Opening the same file in neovim (right) yields a bunch of errors.

Edit: After reviewing what happens when the FileChangeWatcher fires, there is a heuristic in O# that will match a new code file to an existing project based on whether the code file exists alongside or beneath the project file on the filesystem. This matching would not persist between sessions unless the project file was updated with the appropriate element.

Is it possible that vscode is doing something on each startup that adds this file?

It seems like, on further glance, that vscode is not providing completion candidates (or hover) for UnityEngine on the newly added file without regenerating the solution file.

[nyngwang]

Any progress now? This also happens after renaming of class. I have to click the button on External Tools > "Regenerate project files" to make MonoBehaviour detected by the LSP.

[niscolas]

I actually was able to maintain a sustainable workflow by creating a second class (let's say Foo.cs) on a already "Synced File" (where the LSP features work normally) and using the Code Action Move type to Foo.cs.
That way it's possible to work on Foo.cs without problems.
But that's just a workaround, but maybe it can lead us somewhere.

[crissNb]

A workaround I have found is to add the following line to Assembly-CSharp.csproj:
<Compile Include="**/*.cs" />

As mentioned above, each Unity code file needs to have <Compile..../> element in the .csproj file.
On neovim (using OmniSharp Roslyn LSP server), it seems like the .csproj file (specifically Assembly-CSharp.csproj) does not get automatically "refreshed" after it changes. The changes to .csproj file only seem to be applied after restarting neovim (and omnisharp).
This doesn't seem to be the case with vscode, however. When making changes to .csproj file (adding the compile element), vscode directly picks up the change and omnisharp server seems to be working as intended.

I believe "Regenerate Project Files" button on Unity just ensures there's the <Compile.../> tag in the .csproj file for newly created/renamed files. There is a Unity plugin for vscode (and a modified version to work with neovim) that automatically regenerates the project files when there's a new file. This is done in Unity though.

I doubt my workaround is going to be a good solution in the long run, mostly because Unity generates this file, which will override the line I've described above.

[niscolas]

I'll test that approach later.
But what I've found is it seems like there're 2 different problems.
There're some repos on GitHub mimicking the behavior of Unity plugins for VSCode and JetBrains Rider, like this: neovim/neovim#17808 (comment)
I even tried to improve on it myself, but even using Unity's API to Regenerate Project Files automatically on file changed, the behavior described in this issue still occurs.

[nickspoons]

I've been looking into this in a similar issue for OmniSharp-vim. From what I've seen, I believe omnisharp-vscode has a file watcher watching the .csproj file, and when it is modified (by Unity, which adds a new <Compile ...> element for the new file) then vscode sends a /filesChanged request for the csproj to OmniSharp-roslyn, which then reloads the project.

I've tried to mimic this /filesChanged request from OmniSharp-vim and works - the new file is now part of the project, without requiring a full OmniSharp-roslyn restart.

[niscolas]

That's great to hear! Is this change on the repo yet?

[nickspoons]

Which repo? OmniSharp-vim? Not yet. But I'm just adding it as a command, :OmniSharpRelosdProject, there aren't file watchers in OmniSharp-vim.

I was letting you know what my findings were in case you wanted to investigate making that /filesChanged request from neovim lsp

[nickspoons]

Oh... 1 issue may be that OmniSharp-vim doesn't run OmniSharp-roslyn on LSP mode. I'm not sure if omnisharp-vscode has switched to LSP mode either? So I don't know if the /filesChanged endpoint will have the same effect from neovim LSP. Hopefully?