* Update dependencies from https://github.com/dotnet/razor-compiler build 20211202.2
Microsoft.AspNetCore.Razor.Internal.Transport
From Version 6.0.1-servicing.21565.21 -> To Version 6.0.2-1.21602.2
* Use transport packages
- So turns out for customers who have moved their `obj` folders out of the solution directory (common for larger apps and done via the MSBuild `BaseIntermediateOutputPath` or `IntermediateOutputPath` property) and then published their app would break our ability to consume future Razor component / project system information. Turns out the `obj` folder + publish combo breaks due to a blatant bug in our `project.razor.json` change detection mechanism. Let me explain: Whenever a project has an `obj` outside of the workspace directory we need to notify the RZLS where to look for said `obj` folder so it can detect `project.razor.json` changes. We do this via a custom endpoint (`razor/monitorProjectConfigurationFilePath`) which takes in a csproj + `project.razor.json` path. So when a user would publish what the IDE would do is move the project to the `Release` configuration to build the app and then immediately move it back to the `Debug` configuration. This in turn would trigger two monitor project configuration file path events because the `Release` config has a different project.razor.json path (`obj/Release/net6.0/project.razor.json`), the two events would be "move to Release folder", "move back to Debug folder". Now the problem is that our caching mechanism in our monitor config endpoint would never update its `project.razor.json` path if it found we were moving from one `project.razor.json` path to another. Therefore, when we initially moved to the "Release" folder it'd start monitoring that folder; however, once we tried to move to the `Debug` folder it would never start a new watcher for the Debug folder; instead it would stop the release folder watching and then sit their twiddling its thumbs :D.
- Note: You can also reproduce this behavior by manually going to Debug -> Release -> Debug.
- Fix was to make it so when we moved from different `obj` folders to always stop/reconstruct the detectors no matter what.
- Added tests to validate that publish scenarios work as expected.
Fixes#5757
* Add project capability opt-out to use legacy Razor editor.
- In the past there were various opt-outs to force the .NET Core editor in non-.NET Core scenarios. When we moved to the LSP editor we lost some of these capabilities. This changeset re-adds a similar functionality.
For context see: https://github.com/dotnet/roslyn/discussions/54068
* Add comment.
* Localized file check-in by OneLocBuild Task: Build definition ID 262: Build ID 1480205
* Localized file check-in by OneLocBuild Task: Build definition ID 262: Build ID 1481798
* Localized file check-in by OneLocBuild Task: Build definition ID 262: Build ID 1481940
* Localized file check-in by OneLocBuild Task: Build definition ID 262: Build ID 1482438
* Fix HTML completion race when typing too quickly
- There was a race when typing too quickly our synchronization mechanism would try and reduce the work that was done to cancel pre-existing requests. So in the scenario when you were to type `<tr` what would happen is that 3 completion requests would fire:
1. Triggered completion for `<`
2. Typing completion for `t`
3. Typing completion for `r`
Now when we sped things up we were able to process requests in parallel which meant that we could handle simultaneous requests for `<`, `t` and `r` all at the same time; however, this in turn results in an interesting behavior where if we ask for completion at `r` while `<` and `t` are still active our synchronization mechanism would aggressively cancel the older requests. For completion this is catastrohpic because it would result in a 0 length completion list because HTML does not respect completion requests beyond trigger characters and the beginning of the word.
- To fix this issue I added a new mechanism for synchronization which takes a flag `rejectOnNewerParallelRequest` which states do not reject a synchronization request aggressively if this flag is `true`. Now this doesn't mean the requests never get rejected. If there's a batched document update or document close / open this will still reject the document; it just means that on the requesting of synchronization that older completion requests are not rejected eagerly.
- Added tests to our projection and synchronization stack to account for this
- Ensured that these changes are not breaking changes so marked some bits as virtual.
### Before
### After
Fixes#5743
* Update src/Razor/src/Microsoft.VisualStudio.LanguageServer.ContainedLanguage/LSPDocumentSynchronizer.cs
Co-authored-by: Allison Chou <allichou@microsoft.com>
* Fix newer tests.
Co-authored-by: Allison Chou <allichou@microsoft.com>
- After digging through countless customer logs I've had a hell of a time finding out why Debug/Release project.razor.json's occasionally result in lack of component IntelliSense. This PR introduces logging to key points that will help investigate what's going on with #5757.
- We have two entry points on the Razor language server that deal with project.razor.json. These two are the `MonitorProjectConfigurationFilePathEndpoint` which is responsible for monitoring external project.razor.json locations (if you set your obj directory to something outside of the workspace) and the `ProjectConfigurationStateSynchronizer` which listens to `project.razor.json` file changes and then harvests information and pushes it to our language server project manager.
- For these two I enabled nullability + added logging to better understand what's going on under the covers.
Part of #5757
This required updating the VS protocol assemblies to 17.1.2, as that was
where this method name was introduced (though it's been in the LSP spec
for a long time).
Allison Chou
N. Taylor Mullen
dotnet-maestro[bot]
Pranav K
Ryan Brandenburg
dotnet bot
David Wengier
David Wengier
Will Godbe
Jimmy Lewis
