omnisharp-roslyn: Omnisharp does not find Unity3D assemblies

.NET 6.0 build of OmniSharp does not support Unity.

@harrisonmg I had better luck by avoiding the run script entirely, I tried to mess with it quite a bit like you did. Here is the way I setup the server with nvim, instead of calling the run script I call omnisharp using global mono directly.

locallspconfig = require "lspconfig"
local pid = vim.fn.getpid()
local omnisharp_bin = "/home/mark/.local/share/nvim/lsp_servers/omnisharp/omnisharp/omnisharp/OmniSharp.exe" 

return {
    cmd = { "mono", omnisharp_bin, "--languageserver","--hostPID", tostring(pid) },
    filetypes = { "cs", "vb" },
    init_options = {},
    on_new_config = function(new_config, new_root_dir)
          if new_root_dir then
            table.insert(new_config.cmd, '-s')
            table.insert(new_config.cmd, new_root_dir)
          end
        end,
    root_dir = lspconfig.util.root_pattern("*.sln");
}

Go to /usr/lib/mono and check what the latest version you have, then set FrameworkPathOverride to point to that folder.

For me it’s worked setting it to both /usr/lib/mono/4.5 and /usr/lib/mono/4.8-api.

export FrameworkPathOverride=/lib/mono/4.5

Thank you everyone for your input. To summarize, the issue is that the bundled Mono cannot find any 3rd party assemblies at all. It is the responsibility of the client to start the server with a global Mono installation. I have for now modified the run script to change one variable:

bin_dir=/usr/bin  # Previous value: ${base_dir}/bin

That way when the run script starts the server ("${mono_cmd}" "${omnisharp_cmd}" "$@") it will use usr/bin/mono as the Mono binary.

Now the next question is how to tell the server which Mono to use. From looking at the run script there does not appear to be any way of passing a command-line option or environment variable to the script. So I figure the best course of action would be to forego the run script altogether and just invoke mono and omnisharp directly. From the looks of it the script does not really do much anyway.

Is this the correct way? From what I can understand the VS Code plugin does the same. Please correct me if I’m wrong, I don’t actually know TypeScript, so I’m just taking an educated step.

@harrisonmg I had better luck by avoiding the run script entirely, I tried to mess with it quite a bit like you did. Here is the way I setup the server with nvim, instead of calling the run script I call omnisharp using global mono directly.

locallspconfig = require "lspconfig"
local pid = vim.fn.getpid()
local omnisharp_bin = "/home/mark/.local/share/nvim/lsp_servers/omnisharp/omnisharp/omnisharp/OmniSharp.exe" 

return {
    cmd = { "mono", omnisharp_bin, "--languageserver","--hostPID", tostring(pid) },
    filetypes = { "cs", "vb" },
    init_options = {},
    on_new_config = function(new_config, new_root_dir)
          if new_root_dir then
            table.insert(new_config.cmd, '-s')
            table.insert(new_config.cmd, new_root_dir)
          end
        end,
    root_dir = lspconfig.util.root_pattern("*.sln");
}

Thanks, but no dice. I don’t know what else I could be doing wrong. I’m using the Mono build of OmniSharp mentioned by @nyngwang and mono 6.8.0.105 (though 6.12.0.147 also didn’t work).

I still get a load of

"OmniSharp.Extensions.LanguageServer.Server.LspServerOutputFilter: Tried to send request or notification before initialization was completed and will be sent later OmniSharp.Extensions.JsonRpc.Client.OutgoingNotification | @Request='OmniSharp.Extensions.JsonRpc.Client.OutgoingNotification'"

messages until the server eventually initializes after an unacceptably long few minutes (perhaps because of all the type or namespace not found errors?)

This is driving me nuts.

The Mono build of OmniSharp, but started with global Mono installation from your machine (not the lightweight Mono OmniSharp ships with).

I still get the same issue that MonoBehaviour and other Unity types cannot be found. Even with the fix that @HiPhish gave.

I’m having the same issue as @HiPhish, omnisharp with neovim LSP. Omnisharp works but acts like all Unity related things don’t exist. This thread was helpful but didn’t get me all the way home. My details:

mono: 6.12.0.147 msbuild: 16.10.1 omnisharp run script:

#!/usr/bin/env bash

base_dir="/opt/omnisharp"
bin_dir=${base_dir}/bin
etc_dir=${base_dir}/etc
omnisharp_dir=${base_dir}/omnisharp

mono_cmd=/usr/bin/mono

config_file=/etc/mono/config

omnisharp_cmd=${omnisharp_dir}/OmniSharp.exe
no_omnisharp=false

export MONO_CFG_DIR=${etc_dir}
export MONO_ENV_OPTIONS="--assembly-loader=strict --config ${config_file}"
export FrameworkPathOverride=/lib/mono/4.8-api # this line doesn't seem to change anything, neither does ../4.5

"${mono_cmd}" "${omnisharp_cmd}" "$@"

The only thing in my lsp.log is a bunch of

[WARN][2021-10-20 16:19:00] ...lsp/handlers.lua:401     "OmniSharp.Extensions.LanguageServer.Server.LspServerOutputFilter: Tried to send request or notification before initialization was completed and will be sent later OmniSharp.Extensions.JsonRpc.Client.OutgoingNotification | @Request='OmniSharp.Extensions.JsonRpc.Client.OutgoingNotification'"

until the server initializes after a number of minutes.

Anything else I can try? Thanks!

EDIT: Also, I’ve manually generated .csproj files through the Unity editor for the following categories: embedded packages, local packages, registry packages, and built-in packages. I’ve experimented with other combinations to no avail.

@HiPhish Thanks!

Mono binaries on latest MacOS’s are installed elsewhere… Thought I post it here as it could be of any help for others.

bin_dir=/Library/Frameworks/Mono.framework/Versions/Current/bin

Note: Unity doesn’t generate .sln and .csproj files. So for Neovim you have to create them yourself, in case of new projects. Or open a .cs file in VS or Rider and let them auto generate it for you.

Hi I’m on Windows using nvim lspconfig omnisharp language server. It doesn’t recognize the assemblies as well. When loading a basic script it says that it couldn’t find monobehavior class

@axelson That’s a VSCode setting, regarding how the OmniSharp-roslyn process is started.

I will close this because at the end, this is by design - OmniSharp doesn’t ship with reference assemblies for .NET Framework. we will add a better error message in https://github.com/OmniSharp/omnisharp-roslyn/issues/2029 so that it’s clear that full Mono is needed when reference assemblies are not found

ah that could be - not every mono distro has MSBuild bundled

@nickspoons there is a setting omnisharp.useGlobalMono which can be set to always. It then uses global Mono form the PATH to start OmniSharp.exe process. Additionally a custom path can be provided too. https://github.com/OmniSharp/omnisharp-vscode/blob/97768562a4f950db687d5d9314da4a854c9e6f4c/src/omnisharp/launcher.ts#L264-L277

@snowgoon88 if you have trouble with VS Code, please open an issue in https://github.com/OmniSharp/omnisharp-vscode and provide your OmniSharp log with omnisharp.logginglevel: "debug" enabled.

When OmniSharp starts on its own embedded Mono it will have no reference assemblies for desktop …NET and Unity and other non-.NET Core development won’t work or be limited.

In VS Code there is a setting to start OmniSharp on global Mono instead and that allows full compatibility with all desktop .NET development. I would imagine in this case a setting like this is needed too.

However, I don’t think this is an issue for OmniSharp itself as it already provides the necessary tools for achieving this - it’s just the client must make the decisions, therefore I would recommend to move this issue to the client implementation(s).