languages/csharp: add razor support

[CaueAnjos]

It adds the roslyn-ls configuration and the roslyn-nvim plugin. Razor support works partially. The roslyn-nvim team announced that they now support Razor, but I think the version of roslyn-ls available in nixpkgs isn’t up to date. Because of that, Razor files may still produce errors. Aside from this, everything works fine.

This PR should fix #1268

Sanity Checking

• I have updated the changelog as per my changes
• I have tested, and self-reviewed my code
• My changes fit guidelines found in hacking nvf
• Style and consistency
  • I ran Alejandra to format my code (nix fmt)
  • My code conforms to the editorconfig configuration of the project
  • My changes are consistent with the rest of the codebase
• If new changes are particularly complex:
  • My code includes comments in particularly complex areas
  • I have added a section in the manual
  • (For breaking changes) I have included a migration guide
• Package(s) built:
  • .#nix (default package)
  • .#maximal
  • .#docs-html (manual, must build)
  • .#docs-linkcheck (optional, please build if adding links)
• Tested on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin

---

[github-actions]

🚀 Live preview deployed from 9da5d51

View it here:

Debug Information

Triggered by: CaueAnjos

HEAD at: feat/roslyn-ls

Reruns: 2062

[NotAShelf]

Could you target the v0.8 branch? The LSP experience was mostly overhauled and improved, so this PR will likely benefit from the new API.

[CaueAnjos]

I've noticed a lot has changed. I’m working on it! 😁

[Soliprem]

we merged 0.8 into main! So you can target main directly, now (sorry for the double switch)

[CaueAnjos]

I figured it out! It wasn't a roslyn-ls version problem. Razor wasn't working correctly because the .razorExtension wasn't being mapped. Now everything works perfectly.

[poseidon-rises]

I actually added roslyn-ls in v8.0 already, you should be able to use it now that's pulled into main.

[CaueAnjos]

I actually added roslyn-ls in v8.0 already, you should be able to use it now that's pulled into main.

I noticed. It’s a pretty good implementation. I’ve just added Razor support. Your implementation doesn’t have that, and I need it for Blazor projects.

[horriblename]

Thanks, but overall, I think we should wait for the nixpkgs PR to land first before adding razor support (see my other comments)

[horriblename]

1. add the package to vim.extraPackages instead
   2. the package needs to be overridable somehow, preferably with vim.lsp.servers.roslyn.cmd, or if it's really not doable, add an option vim.languages.csharp.lsp.package (this deviates from our usual pattern so an appropriate warning in case cmd is used would be appreciated) doesn't really apply if we wait for the nixpkgs PR

[horriblename]

use vim.fn.stdpath("data") .. "/mason" instead of hard-coding ~/.local/share

I don't really like this approach overall. I would rather wait until https://github.com/NixOS/nixpkgs/issues/472357 is merged. Will probably need to patch out the warning in roslyn-nvim unless they start supporting it themselves though

[horriblename]

this is technically a breaking change, a warning about removal of "roslyn_ls" in lsp.servers would be nice

[CaueAnjos]

Now I warn it on lsp.servers. Just not sure if I did it the right way.

[CaueAnjos]

I don't really like this approach overall. I would rather wait until https://github.com/NixOS/nixpkgs/issues/472357 is merged. Will probably need to patch out the warning in roslyn-nvim unless they start supporting it themselves though

I’ve rethought the symlink approach, and I now believe this solution is more reproducible and, overall, more stable.
The code is also prepared for the future .razorExtension bundled with roslyn-ls.

[horriblename]

is this ready for review now?

[horriblename]

the original root_dir function and the new root_marks are not equivalent, the root_marks do not match ProjectName.csproj and ProjectName.sln, don't change these

[horriblename]

Don't add the LSP package to PATH, set the cmd for roslyn directly with vim.lsp.servers.*.cmd

[horriblename]

I don't think abusing $MASON like this is a good idea. What if some other plugin sees $MASON and starts doing mason things it's not supposed to? What if another LSP needs this hack as well?

Adapting from NixOS/nixpkgs#472357 (comment), something like this should work (untested):

let
  pkg = pkgs.vscode-extensions.ms-dotnettools.csharp;
  pluginRoot =  "${pkg}/share/vscode/extensions/ms-dotnettools.csharp";
  exe ="${pluginRoot}/.roslyn/Microsoft.CodeAnalysis.LanguageServer":
  razorSourceGenerator = "${pluginRoot}/.razorExtension/Microsoft.CodeAnalysis.LanguageServer":
  razorDesignTimePath = "${pluginRoot}/.razorExtension/Targets/Microsoft.NET.Sdk.Razor.DesignTime.targets";
  razorExtension = "${pluginRoot}/.razorExtension/Microsoft.VisualStudioCode.RazorExtension.dll";

in {
  cmd = mkLuaInline ''
    {
      "${exe}",
      "--stdio",
      "--logLevel=Information",
      "--extensionLogDirectory=" .. vim.fs.dirname(vim.lsp.get_log_path()),
      "--razorSourceGenerator=${razorSourceGenerator}",
      "--razorDesignTimePath=${razorDesignTimePath}",
      "--extension=${razorExtension}",
    }
  '';
}

set vim.lsp.servers.roslyn.cmd to the above

[CaueAnjos]

This solution works perfectly. The only required adjustment is to prepend dotnet before "${exe}". Without this, roslyn-ls incorrectly reports that the .NET SDK is missing, even though it is installed.

There is one additional observation: I tested Razor support in csharp-ls, and while it does function, the implementation is quite minimal. It only recognizes .cshtml files and offers limited functionality beyond basic support. Nevertheless, I decided to include it.