Adding client capabilities to OOP client initialization data

[alexgav]

Summary of the changes

• Pass client capabilities to OOP just once, during the initial client collection
• Proffer client capabilities to other remote services via RemoteClientCapabitiliesService
• Move common code for the cohost and remote ClientCapabilitiesService to a base class in Workspaces layer
• Fixup tests to init necessary capabilities

Fixes: #11102

[DustinCampbell]

Thanks for submitting this! I'm really glad to see it happening. I have a few suggestions, but it looks like there are test failures. (Note that you can always check for test failures by running build.cmd -test at the command-line before submitting.)

[alexgav]

but it looks like there are test failures.

thanks, I ran and fixed cohosting tests, missed that one. just submitted a fix.

(Note that you can always check for test failures by running build.cmd -test at the command-line before submitting.)

thanks, didn't know about that parameter

[davidwengier]

Does that do something different to just running tests in Test Explorer??

[davidwengier]

Lovely! Just a few minor tweaks to make everything really nice and neat.

Also at some point we need to be a bit smarter about the LSP initialization, but I'll log a separate issue for it.

[DustinCampbell]

Does that do something different to just running tests in Test Explorer??

Technically, yes; practically, no. If something throws on a thread after a thread has finished running, it'll fail at the command-line, but Test Explorer will eat the exceptions. That's pretty uncommon though, so practically, there's no real difference. 😄

Personally, I like to run them at the command-line so they run just as they do in CI. That gives me some confidence that any test failures in CI for Window-Debug or Windows-Release aren't mine. Plus, I get to see if there any warnings (such as unused using) that would break the CI build before pushing. Also, I always trip over the fact that our integration tests our included in the Test Explorer. Too often when making a compiler change, I'll forget and Ctrl+A to select all tests and accidentally start integration tests running. build.cmd -test just runs unit tests.

[davidwengier]

Also, I always trip over the fact that our integration tests our included in the Test Explorer. Too often when making a compiler change, I'll forget and Ctrl+A to select all tests and accidentally start integration tests running. build.cmd -test just runs unit tests.

May I recommend a "RazorToolingTests.playlist" playlist file, that includes everything but compiler and integration tests, so one click of the "Run All In View" button runs only the interesting things.

[DustinCampbell]

Also, I always trip over the fact that our integration tests our included in the Test Explorer. Too often when making a compiler change, I'll forget and Ctrl+A to select all tests and accidentally start integration tests running. build.cmd -test just runs unit tests.

May I recommend a "RazorToolingTests.playlist" playlist file, that includes everything but compiler and integration tests, so one click of the "Run All In View" button runs only the interesting things.

I do know about that, but I did say "too often when making a compiler change." 😄