Allow additional omnisharp settings to be overridden at the workspace level

Currently omnisharp.path and omnisharp.useGlobalMono cannot be overridden at the workspace level.

Reason for change:

Currently, due to an architectural issue in roslyn, omnisharp’s scripting support does not support custom scripting hosts. Because of this a custom omnisharp build must be used in order to use a custom scripting host. The problem with that is the omnisharp implementation is global.

Allowing omnisharp.path would allow the omnisharp implementation to be overridden only where needed.

The reason for needing omnisharp.useGlobalMono is because setting it to never is the only way to run a custom omnisharp build without mono. My current omnisharp build doesn’t use mono (.net 5 instead).

Having these two settings available at the workspace level would allow the vscode extension to be used in custom scripting scenarios without affecting the normal operation machine wide.

[MiniguyBrendan]

I know that this issue is sort of in limbo, but I just wanted to echo that this is an issue for me, too.

I work on a multiplayer game that has a server component (dotnet core) and the actual game client (Unity’s mono runtime). I’d like to be able to use vscode to write code for both components at the same time, but omnisharp.useGlobalMono cannot be overridden at the workspace level.

I lose all Intellisense highlighting on one of the two windows depending on how the value is set. In this situation (where the absence or presence of a flag determines whether or not the specific project works), wouldn’t this be a good case for making this a workspace flag?

[filipw]

I work on a multiplayer game that has a server component (dotnet core) and the actual game client (Unity’s mono runtime). I’d like to be able to use vscode to write code for both components at the same time, but omnisharp.useGlobalMono cannot be overridden at the workspace level.

There is a new feature that shipped in OmniSharp 1.37.5 that should be helpful here. You can set "omnisharp.useGlobalMono": "always" (to make everything compatible with .NET Framework projects such as Unity) and then create omnisharp.json in the root of the project that you’d want to override this behavior (.NET Core project in your case) and add the following content there:

{ 
  "msbuild": { 
       "useBundledOnly": true 
   } 
}

This will force the OmniSharp project loader to skip MSBuild from global Mono and use the bundled one instead for that given folder. The bundled MSBuild is version 16.8, compatible with .NET Core (as opposed to the incompatible version 16.6 in Mono 6.12).

Alternatively, if you install nightly Mono (https://www.mono-project.com/download/nightly/) 6.13, it works both with latest .NET Core SDKs and with .NET Framework projects such as Unity since it ships with MSBuild 16.8 too. Then "omnisharp.useGlobalMono": "always" just works for everything, although I can understand having a nightly Mono may not be desirable.