What is expected by the client for workspace/_roslyn_projectNeedsRestore?

[seblyng]

Hi, I am the maintainer of https://github.com/seblyng/roslyn.nvim which configures the roslyn language server to work in neovim.

I am wondering a bit about what is expected by the client to be done for workspace/_roslyn_projectNeedsRestore.

Trying to look at how vscode has implemented this: https://github.com/dotnet/vscode-csharp/blob/main/src/lsptoolshost/projectRestore/restore.ts#L40-L61 it seems like it should be relatively straight forward. It basically just sends it straight back to workspace/_roslyn_restore.

Trying to do something similary in neovim doesn't seem to work as I would expect however.

For context, I am testing this with the csharpier repo: https://github.com/belav/csharpier, and opening this file csharpier/Src/CSharpier.Cli/IConsole.cs.

The handler is correctly triggered, and the result I get from the roslyn server is this:

{
  projectFilePaths = { "/Users/sebastian/csharpier/Src/CSharpier.Cli/IConsole.cs" }
}

already here I feel like I am misunderstanding something. The usage of projectFilePaths as the name makes me expect the csproj file for the project from which the file I opened is a part of. So /Users/sebastian/csharpier/Src/CSharpier.Cli/CSharpier.Cli.csproj

Maybe it is just me misinterpreting things, but then I try to send a request to workspace/_roslyn_restore with params being:

{
  projectFilePaths = { "/Users/sebastian/csharpier/Src/CSharpier.Cli/IConsole.cs" }
}

which seems to be the same thing that vscode does.

However, then I get this response back:

Restore started
Running dotnet restore on /Users/sebastian/csharpier/Src/CSharpier.Cli/IConsole.cs
__________________________________________________
Project "/Users/sebastian/csharpier/Src/CSharpier.Cli/IConsole.csproj" (Restore target(s)):

/usr/local/share/dotnet/sdk/10.0.100-preview.5.25277.114/NuGet.targets(848,5): error MSB3202: The project file "/Users/sebastian/csharpier/Src/CSharpier.Cli/IConsole.csproj" was not found.
Done building project "IConsole.csproj" -- FAILED.
Failed to run restore on /Users/sebastian/csharpier/Src/CSharpier.Cli/IConsole.cs
Restore complete

which is weird because the .csproj file it tried to locate does obviously not exist.

Here is some (maybe) relevant discussions: seblyng/roslyn.nvim#233 (comment)

[RikkiGibson]

If your client receives a message like projectNeedsRestore for path/to/app.cs, then, you basically should just run dotnet restore path/to/app.cs. I believe preview5 is too old for the restore command to work on .cs files, please try also using the latest preview .NET 10 SDK to restore.

This is some wonkiness related to file-based apps. Basically the way our project system works is we see the .cs app file as also being a project. In certain spots we quietly swap the .cs extension to .csproj despite no such .csproj file actually existing. However the projectNeedsRestore command should not be one of them.

[seblyng]

So, I could for example find the csproj file that belongs to each of the .cs files I am receiving, and then pass that along to workspace/_roslyn_restore so that the params is like this in my specific case?

{
  projectFilePaths = { "/Users/sebastian/csharpier/Src/CSharpier.Cli/CSharpier.Cli.csproj" }
}

and in case I receive .csproj files I just do nothing of course(?)

Something like this then?:

    ["workspace/_roslyn_projectNeedsRestore"] = function(_, result, ctx)
        local client = assert(vim.lsp.get_client_by_id(ctx.client_id))

        -- Convert potential .cs files into their respective .csproj file
        local projects = vim.iter(result.projectFilePaths)
            :map(function(path)
                local ext = vim.fn.fnamemodify(path, ":e")
                if ext == "cs" then
                    return vim.fs.find(function(name)
                        return name:match("%.csproj$")
                    end, { type = "file", path = vim.fn.fnamemodify(path, ":p:h") })[1]
                else
                    return path
                end
            end)
            :totable()

        ---@diagnostic disable-next-line: param-type-mismatch
        client:request("workspace/_roslyn_restore", { projectFilePaths = projects }, function(err, response)
            if err then
                vim.notify(err.message, vim.log.levels.ERROR, { title = "roslyn.nvim" })
            end
            if response then
                for _, v in ipairs(response) do
                    vim.notify(v.message, vim.log.levels.INFO, { title = "roslyn.nvim" })
                end
            end
        end)

        return vim.NIL
    end,

TLDR;
Basically just trying to map potential .cs files into their respective .csproj files, and then call workspace/_roslyn_restore with those files

[RikkiGibson]

There should be no need to interpret the paths the server is asking you to restore. You should be able to take each entry in projectFilePaths and pass it straight through to dotnet restore. No need to check if a similarly named .csproj exists or things like that.

We do also have an issue where, if the solution is not yet loaded (i.e. the initial loading process is ongoing), we are "over-eager" in treating .cs files as if they are file-based apps. That's something I am meaning to address later on when possible. But once the language server has loaded the solution/projects it should not be asking you to restore .cs files that are part of a project.

[jasonmalinowski]

And indeed you wouldn't want to map to the .csproj, since that'd then break restore for file-based apps.

@RikkiGibson was that "csproj not found" also a symptom of something in Directory.Build.props breaking the SDK? Like we saw in Roslyn?

[RikkiGibson]

It looks like in this case the client was changing .cs to .csproj internally and then trying to restore, and there was simply no such file on disk. That should be resolved by just using the path that the language server gives without modification.

I think there have been issues in the past where some msbuild target expects the virtual project (which represents how to build/interpret the file-based app) to be on disk, but it is not. I don't recall all the specific issues but I know Jan had inserted some workarounds in the virtual project content itself to deal with some of them.

[seblyng]

Hmm okay, but I don't understand why the server sends a project needs restore to the cs file in my example? It seems like it always sends that with the cs file I open first after starting the server. All files opened after this seems to send files that are actually able to be restored.

Could it be some bug in the server?

[seblyng]

Okay, I digged more into the implementation of vscode, and I see that they are also sending along a partialResultToken along with the files. This seems to silence all output from the workspace/_roslyn_restore, and that the client instead needs to listen through the progress emitted by the server.

This seems to somewhat fix this issue because it immediately send two workspace/_roslyn_projectNeedsRestore. Once for the .cs file (which do seem like a bug IMO), and then for a list of .csproj files which it is actually able to restore