-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OmniSharp settings #44
Comments
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 // 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.
The text was updated successfully, but these errors were encountered: