Configuring Omnisharp to open a sln solution file

[Noah-Huppert]

I am trying to edit a C# project with a sln solution file. I have been trying to configure eglot to launch omnisharp with awareness of this file, because there are some assemblies and external types which I would like to make eglot aware of.

I found in the Omnisharp docs a way of launching Omnisharp with awareness of a sln file. I then tried configuring eglot to launch Omnisharp this way:

(setq eglot-server-programs (remove '(csharp-mode "omnisharp" "-lsp") eglot-server-programs))
  (add-to-list 'eglot-server-programs '(csharp-mode "omnisharp" "*.sln" "-lsp"))

I have also tried the variations omnisharp -s *.sln -lsp (Omnisharp didn't launch for this one, didn't like the -s flag) and omnisharp myproject.sln -lsp (Failed to connect). However with all of these variations eglot does seem to be able to connect. I think it might have something to do with the fact that invoking Omnisharp this way doesn't start the LSP? I'm not really sure.

Does anyone have experience trying to get eglot to open a sln project file?

The main goal I have here is to try and get Emacs + eglot working for Godot C# development. I'm pretty sure the sln file that Godot generates for my game will configure Omnisharp to look in the .mono/assemblies directory where I found the files GodotSharp.{dll,pdb,xml} which I think contain the external type definitions eglot must be made aware of.

[Noah-Huppert]

In my case I had to do 2 things to solve this issue. Item #2 might not be relevant but I want to post it just in case it is and others have this issue.

1. Ensure that the OmniSharp binary is being run in your project's directory. Due to the way I had installed OmniSharp (on Linux so it was a bit custom through a package manager) the OmniSharp binary was being run with a working directory of /usr/local/bin. This meant it couldn't find my solution file because I was giving a relative path. I figured this out when I saw an error message from the OmniSharp LSP server which said it couldn't find the myproject.sln file. Once I editted my install to make OmniSharp run in my project directory I was able to get eglot working.
2. I installed the Mono version of OmnisSharp. I'm not quite sure if this is absolutely required, but I think it makes sense because Godot uses Mono and I assume there is some formatting difference of Mono vs .NET dll files which might have caused the Godot dll files to not be read properly.

[joaotavora]

Changed this to "Show and tell", where I'm trying to build a small database of "known to be working" setups.

[joaotavora]

Ensure that the OmniSharp binary is being run in your project's directory. Due to the way I had installed OmniSharp (on Linux so it was a bit custom through a package manager) the OmniSharp binary was being run with a working directory of /usr/local/bin.

This is indeed very important, always. But the working directory of a given process is controlled by the way it is invoked: the installation method of the executable file of the process is not relevant. And Eglot makes sure to use the working directory of the project. So something else must have been at play.

[Noah-Huppert]

Ensure that the OmniSharp binary is being run in your project's directory. Due to the way I had installed OmniSharp (on Linux so it was a bit custom through a package manager) the OmniSharp binary was being run with a working directory of /usr/local/bin.

This is indeed very important, always. But the working directory of a given process is controlled by the way it is invoked: the installation method of the executable file of the process is not relevant. And Eglot makes sure to use the working directory of the project. So something else must have been at play.

So I use Void Linux and they didn't have a package for OmniSharp. So I used Salt Stack (a configuration as code tool) to download the OmniSharp, unzip it, and then add a custom script to /use/bin/local/ named omnisharp with the contents:

#!/usr/bin/env bash
cd /opt/omnisharp
mono ./OmniSharp.exe "$@"

This was my fault making a bad script. This caused the wrong directory error. When I ran omnisharp it was running in /opt/omnisharp.

Now the script is:

#!/usr/bin/env bash
mono /opt/omnisharp/OmniSharp.exe "$@"

Here is the complete salt state I made for installing OmniSharp:
https://github.com/Noah-Huppert/linux-install/tree/master/salt/base/omnisharp
https://github.com/Noah-Huppert/linux-install/tree/master/pillar/base/omnisharp

[joaotavora]

Ah ok, that makes sense, then.

…

On Sun, Jul 31, 2022, 00:36 Noah Huppert ***@***.***> wrote: Ensure that the OmniSharp binary is being run in your project's directory. Due to the way I had installed OmniSharp (on Linux so it was a bit custom through a package manager) the OmniSharp binary was being run with a working directory of /usr/local/bin. This is indeed very important, always. But the working directory of a given process is controlled by the way it is invoked: the installation method of the executable file of the process is not relevant. And Eglot makes sure to use the working directory of the project. So something else must have been at play. So I use Void Linux and they didn't have a package for OmniSharp. So I used Salt Stack (a configuration as code tool) to download the OmniSharp, unzip it, and then add a custom script to /use/bin/local/ named omnisharp with the contents: #!/usr/bin/env bashcd /opt/omnisharp mono ./OmniSharp.exe "$@" This was my fault making a bad script. This caused the wrong directory error. When I ran omnisharp it was running in /opt/omnisharp. Now the script is: #!/usr/bin/env bash mono /opt/omnisharp/OmniSharp.exe "$@" Here is the complete salt state I made for installing OmniSharp: https://github.com/Noah-Huppert/linux-install/tree/master/salt/base/omnisharp https://github.com/Noah-Huppert/linux-install/tree/master/pillar/base/omnisharp — Reply to this email directly, view it on GitHub <#1003 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC6PQYUD52QOKCZAL2S3ELVWW4ABANCNFSM55DXMULQ> . You are receiving this because you commented.Message ID: ***@***.***>