Remove cohost feature flag, and hardcode to true#12669
Remove cohost feature flag, and hardcode to true#12669davidwengier merged 3 commits intodotnet:mainfrom
Conversation
|
Test insertion, just for fun: https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/699512 |
| return true; | ||
| } | ||
|
|
||
| public CapabilityCheckResult IsDotNetCoreProject(string documentFilePath) |
There was a problem hiding this comment.
Unrelated to this PR, but it seems that if we wanted to 'fix' the weird '.NET Framework but with SDK style projects' we could define a capability that they could put in their projects that we could detect and fallback to .NET Framework editor.
//cc @dbreshears
There was a problem hiding this comment.
In theory, yes, and thats why #12332 is still open, and I fully support doing that work if we get enough user feedback about it. In practice I tried this and it needs more than just changes in our repo though. That might be 5 minutes of work in the Web Tools repo, but equally it could mean that the .NET Framework editor has some code that relies on/expects the native csproj project system, and won't ever work with CPS.
|
Test insertion failed, looks like there are still tests that turn off cohosting. Note to self: Don't merge this yet! |
|
New test insertion run: https://devdiv.visualstudio.com/DevDiv/_git/VS/pullrequest/699512 |
2 participants
Fixes #12656
This leaves most of the code in place, otherwise it's a very viral process that results in deleting the entire old LSP server, and we aren't planning on doing that until 18.5. BUT I did decide to disconnect a few choice MEF services that no-op with cohosting, so we might get some improvements in DDRIT/Speedometer as well.