- Moved from 3.4.0 Roslyn to 3.6.0-3.20168.4 for tooling builds.
- As part of this change I found that our package versions were starting to get really confusing for which Roslyn packages were runtime vs. which ones were tooling. Therefore, I rebranded each of the versions to be `Tooling_` or `Runtime_` accordingly. Moved all `VSIX_` => `Tooling_`.
- Roslyn's bits depended on a newer `StreamJsonRpc`, `Microsoft.VisualStudio.Threading` and `Microsoft.VisualStudio.LanguageServer.Client` packages so updated those dependencies to not have version conflicts.
- This new update brought in loads of new analyzers. Went through the warnings and either applied the fix or suppressed.
- This is in preparation for consuming new pieces from latest Roslyn packages.
\n\nCommit migrated from df5261e418
- Prior to this we would start tracking LSP documents when an `ITextView` was associated with our `ITextBuffer`. The issue with this is when the `ILanguageClient` infrastructure initializes itself before we do and starts our `LanguageServer` it's we start retrieving requests that require access to our `LSPDocumentManager`. That's an issue because our `LSPDocumentManager` may not have been initialized yet resulting in failure to fulfill requests.
- Changed how we initialize `ITextBuffer`s. Before we were setting up all of the logic to change the content type of a text buffer and populate its properties at the `EditorFactory` layer; however, how we were doing it (waiting for the ITextBuffer to load) resulted in `ITextDocumentListener` events firing prior to our content type changes would occur. This is a problem becasue the `ILanguageaClient` infrastructure will start making its decision to turn on LSP features for your `ITextBuffer` at the point and time. Now we change the `ITextBuffer`s content type (and set properties) during the `ITextDocumentListener` created pipeline.
This resulted in almost all of our logic in our editor factory to be split out into two classes.
1. `LSPEditorFeatureDetector`, we needed to be able to detect the "enabledness" of features in two locations. Once at the `EditorFactory` layer to ensure we know when to disallow other editor factories participation in the `ITextBuffer` creation and a second at the `ITextDocumentListener` layer when we inspect an `ITextDocument` and need to determine if we want to "initialize" it (change its content type etc.).
2. `RazorLSPTextDocumentCreatedListener`, this is our `ITextDocumentListener` i've been referring to. It now houses the logic on how to change the content type and populate the `ITextBuffer`'s properties.
- Changed our `LSPDocumentManager` to no longer depend on `ITextView`s for ref counting documents. Instead we just take an `ITextBuffer` and keep an internal count of how many times we've been asked to track a document. In practice this number never goes past 1 however it doesn't hurt to be defensive.
- Added IVT from CodeAnalysis.Razor to our LanguageServerClient project in order to enable the retrieval of our `FilePathComparison` type.
- Given the new refactoring of our feature detector and the `ITextDocumentListener` pieces I was able to add extensive testing to ensure all things work as expected.
Fixes dotnet/aspnetcoredotnet/aspnetcore-tooling#19160
\n\nCommit migrated from d0a7dfce09
- This is a pre-requisite work item to run our language server in-process in Visual Studio. VS is a .NET framework application so we can't have a language server which targets netcoreapp be loaded. Therefore, in order to account for this I needed to re-target our language server library to netstandard2.0 so it can be referenced via a netcoreapp (rzls.exe) and a .NET framework app.
- Added a new `rzls` project to be the maintainer of our OOP language server
- Had to make adjustments to the existing language server project to be compatible with netstandard2.0.
- Created a new `RazorLanguageServer` type to initiate our Language Server but not start and initialize it. To enable a consumer to initialize the new language server I had to use private reflection to `Initialize` O#'s internal type. This is a temporary measure which I intend to expand the O# lib to make their Initialize method public.
dotnet/aspnetcoredotnet/aspnetcore-tooling#19185
\n\nCommit migrated from 79841b9371
LSP Razor formatting for Razor code block directives
- Support for @code/@functions block formatting
- Except when it contains Markup or other Razor constructs
- Added a RazorFormattingService which is invoked by the RazorFormattingEndpoint.
- Added a custom razor/rangeFormatting command that the server can use to ask the client to format a range of the projected C# or HTML document
- Added a CSharpFormatter and HTMLFormatter that invoke the above mentioned command
- Added FormattingSpan and its corresponding visitor to represent Razor understanding of indentation
- Moved the document mapping code to a separate RazorDocumentMappingService service for ease of use
- Added necessary extension methods for convenience. Some of them were copied from Roslyn
- Some cleanup
- Added a C# test formatter to enable unit testing. Right now it calls Roslyn APIs directly. As far as I've seen its behavior is the same as OmniSharp formatting except it doesn't remove trailing whitespace and empty lines. I am following up with people to understand why that is the case.
Added/updated tests
\n\nCommit migrated from 62051b9ad7
- This test has around a pretty high failure rate. Always find myself having to retry builds to work around this. Skipping for now until flakyness can be resolved.
dotnet/aspnetcoredotnet/aspnetcore-tooling#18561
\n\nCommit migrated from 09514f5b4d
This test has around a 50% pass rate. Always find myself having to retry builds to work around this. Skipping for now until flakyness can be resolved.
dotnet/AspNetCoredotnet/aspnetcore-tooling#18543\n\nCommit migrated from 4187049b4f
* Rely on regular restores for RID-specific package restores
* Pin the runtime to a previously shippped version in SDK tests
* Update src/Razor/test/testapps/Directory.Build.targets
\n\nCommit migrated from b0a60a0231
[StaticWebAssets] Updates manifest generation to allow multiple content roots under the same base path for a single project\n\nCommit migrated from 5e957b4c3b
- The Blazor runtime doesn't support adding attributes prior to any sort of content frames being applied. This change ensures that `ComponentAttributes` (how preventDefault / stopPropagation are represented) are handled like other HTML attributes (applied first).
- Updated existing tests and their baselines.
aspnet/AspNetCoredotnet/aspnetcore-tooling#16611
\n\nCommit migrated from 1513cd2a5b
Ryan Brandenburg
N. Taylor Mullen
Tanay Parikh
John Luo
Ajay Bhargav B
Doug Bunting
Ajay Bhargav Baaskaran
Kevin Pilch
Pranav K
dotnet-maestro[bot]
Ryan Nowak
Justin Kotalik
Justin Kotalik
Artak
Javier Calvarro Nelson
William Godbe
Brennan