You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 targeting netstandard2.0 so should build fine against net461 / 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 :)
The text was updated successfully, but these errors were encountered:
tintoy
changed the title
Discussion: merging MSBuild project tools into OmniSharp
Discussion: merging MSBuild project tools into OmniSharp / C# for VS Code
Oct 8, 2017
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 dotnet/vscode-csharp#1156 and dotnet/vscode-csharp#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 :)
The text was updated successfully, but these errors were encountered: