dotnet
Ensure the LSP server is loaded after a solution is closed
Needed for https://github.com/dotnet/razor/issues/9519
Previously Roslyn would load its language server when the first solution is opened in VS so that workspace diagnostics and other such functionality works. When the solution is closed however, VS would shut down the server and the user has to manually open a .cs file to get it to re-load. This ensures it is reloaded on solution open.
This is also needed to unblock cohosting, and cohosting integration tests as well, as without this, when a 2nd solution is opened in VS the user has to open a .cs file before they'll get any tooling in a .razor file, because Razor uses dynamic registration which can only happen after the LSP server has been loaded.
because Razor uses dynamic registration which can only happen after the LSP server has been loaded.
@davidwengier I'm not following the explanation why the second time would be different than the first here -- do we have a problem where a late dynamic registration isn't telling us about things it should be?
@davidwengier I'm not following the explanation why the second time would be different than the first here -- do we have a problem where a late dynamic registration isn't telling us about things it should be?
No, the problem is that dynamic registration can only happen after a server is initialized, and on 2nd load of a solution the only thing that initializes the Roslyn language server is when one of the content types it registers for (C#, VB, F#) is opened in the editor.
So after closing the solution, which shuts down the Roslyn server, if you then open a new solution, and open a Razor document, nothing happens. Nothing has registered for the Razor content type (because under cohosting Razor no longer registers its own server), and the editor doesn't know that Roslyn would want to be loaded for Razor, because that isn't one of the Roslyn content types.
this is likely also fixing a bug with workspace pull diagnostics (if you close a solution and open a new one, you won't get any workspace diagnostics until you open a c# file).
![azure-pipelines[bot] avatar](https://avatars.githubusercontent.com/in/9426?v=4 "Published by a pub.dev verified publisher"){kind=small}
So under the intense load of the integration tests, which constantly close and create (ie, open) new solutions, I found that VS sometimes wouldn't shut the server down before the solution opened event fired. It was rare, but it caused the integration tests to hang in CI. Oddly, it didn't really adversely affect them at all on my machine 🤷♂️
Anyway, I added an extra statement here to do the shutdown too, by firing the StopAsync method. This fixed the problem and didn't seem to have any ill effects on local runs of the integration tests. @dibarbet before I merge, thought you might like to confirm you're okay with this, or if you think we should pursue another avenue?
Okay, David is out. Going to work on the assumption that moving forward is better than backward, and merge this. If there are issues, we can always revert.