Allow additional omnisharp settings to be overridden at the workspace level

[JakeSays]

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.

[JoeRobich]

One issue with this is that workspace settings are commonly committed to repositories. This would then force other developers working on the same repository to use the same path and global mono settings which may not be applicable.

[JakeSays]

If a particular workspace requires a custom version of omnisharp then it would be needed by every developer or the workspace wouldn't be functional. It's similar to requiring specific compiler versions for specific projects, etc.

Actually it could be the .vscode/settings.json file as well - I'm not really sure what the differences are between the workspace and settings files. I've heard that the workspace file is going away.

Another possibility would be to allow the options to be set in the omnisharp.json file.

[indiemini]

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.

[JakeSays]

@filipw This doesn't really solve my issues. I need for mono and msbuild to step completely out of the process and let my own version of omnisharp take over. I just need those two settings exposed, and omnisharp.json would be a perfect place for them.

[filipw]

yes, I was referring to the other message in this thread

[JakeSays]

I know, but I figured while you were here perhaps I could get some feedback since this issue has been completely ignored since I opened it.