Open deathaxe opened 3 days ago
Good point, and yeah, we should do what the vscode extension is doing there (constructing the startup args with the settings included).
I don't think, it's useful to follow the VsCode way of handling settings as most supported omnisharp settings are just not supported.
The easy way was to remove them and point to descriptions about how to create global or project-specific omnisharp.json
The hard way was to support real omnisharp settings in dotted form without translating them by any means. We may want to determine those customized by user to only pass required command line arguments.
The settings
dictionary would look as follows then:
// https://github.com/OmniSharp/omnisharp-roslyn/wiki/Configuration-Options#msbuild
"msbuild.enabled": true,
"msbuild.ToolsVersion": null,
"msbuild.VisualStudioVersion": null,
"msbuild.Configuration": null,
"msbuild.Platform": null,
"msbuild.EnablePackageAutoRestore" : false,
"msbuild.MSBuildExtensionsPath": null,
"msbuild.TargetFrameworkRootPath" : null,
"msbuild.MSBuildSDKsPath": null,
"msbuild.RoslynTargetsPath" : null,
"msbuild.CscToolPath": null,
"msbuild.CscToolExe": null,
"msbuild.loadProjectsOnDemand": false,
"msbuild.GenerateBinaryLogs": false,
// https://github.com/OmniSharp/omnisharp-roslyn/wiki/Configuration-Options#scripting
"script.enabled": true,
"script.defaultTargetFramework": "net461",
"script.enableScriptNuGetReferences": false,
"cake.enabled": true,
"cake.bakeryPath ": null,
"sdk.path": "/usr/local/share/dotnet/sdk/6.0.403/",
"sdk.version": "6.0.403",
// ...
Reading some code from vscode-csharp and OmniSharp Wiki it seems language server settings and configuration is handled completely different, than we are used to.
I may be wrong, but those resources read as if all exposed settings need to be translated to command-line arguments.
At least it seems currently used setting names are not what OmniSharp expects.