Closed tintoy closed 6 years ago
Bump, bump - @DustinCampbell have you had time to look into this yet? No rush, BTW :)
Following other discussions with @david-driscoll I'm going to close this in favour of eventual plans to create a meta-package that potentially includes OmniSharp, Cake, and this extension (among others).
As briefly discussed with @DustinCampbell in omnisharp/omnisharp-vscode#1156 and omnisharp/omnisharp-vscode#1780.
If it's practical to do so, my preference would be for merging (over time) all of the extension's functionality into OmniSharp and deprecating the original extension (as opposed to keeping both extensions around which would, IMHO, be a poorer experience for users since there are bound to be conflicts when they compete to provide intellisense for the same file).
A quick architectural overview is available here. Most of the components are pretty modular so it should be possible to bring over only the bits that constitute the actual MSBuild language service (i.e. understanding what a given location in the
.xxproj
file actually means, either at the XML or MSBuild level). @DustinCampbell if you have a spare couple of moments, would you mind looking over the architectural overview to see if there's anything in there that looks immediately incompatible with how you know OmniSharp works? It's all targetingnetstandard2.0
so should build fine againstnet461
/mono
(which is what I assume OmniSharp builds against).Alternatively, if the idea is simply to use the MSBuild language service as-is from the "C# for VS Code" extension that's even easier from my perspective :)