Step 1: Add HostProject
This is a somewhat complex addition to the ProjectSnapshotManager. Now
that we accept updates from the underlying IDE project system we need to
coordinate those with the Workspace.
This means that ProjectSnapshot itself now also has a version concept.
Step 2: Introduce a new project system based on CPS
We use project capabilities defined by the Razor SDK to determine
whether to rely on MSBuild evaluation to detect the configuration or
whether to fallback to assembly-based detection.
Step 3: Flow RazorConfiguration everywhere
We use now expose the RazorConfiguration to the language service and
editor. This means that we no longer need to detect the project's
configuration asynchronously, it happens much faster now.
- Prior to this we weren't overriding the `GetTagHelpersAsync` method resulting in our TagHelper discovery being executed in-process.
- Removed legacy `ITagHelperResolver` legacy types.
- Exposed `VisualStudioRazorParser`, `DocumentStructureChangedEventArgs` and `ICanHasContextChangedListener` as ways to consume the new parser for a Razor document.
- Split the `VisualStudioRazorParser` into an abstract base and an implementation to avoid internal constructors.
- Changed the parser and corresponding smart indenter to take in document trackers, template engine factories and parser context change listeners. Of these additions the parser context change listeners will be deprecated once we own the TagHelper discovery mechanisms.
- Changed how the parser manages its internal parsing life cycle. It now creates template engines when the document tracker tells it to. So when project changes happen or new documents are opened the parser will re-instantiate its internal parser to ensure that it is parsing against the correct configurations.
- Removed all accessor services in favor of a singular RazorEditorFactoryService. This service is responsible for retrieving/creating various Razor components.
- Changed the code document provider to now use the parser provider in order to locate code documents associated with buffers. Prior to this that logic was hard coded.
- Removed old template engine reconstruction logic in the document tracker now that the parser owns that piece.
- Updated tracker to notify listeners when it's unsubscribing. This is how listeners can know when to tear bits down.
- Refactored/added pieces to the `DefaultVisualStudioRazorParser` in order to improve its unit/integration testing ability.
- Updated existing tests to react to new signatures.
- Added new visual studio razor parser tests, uncommented existing ones, and re-enforced ones that were previously flakey.
- Added various tests for the new services added, i.e. text buffer factory service tests.
#1630
- Created a new `Microsoft.VisualStudio.Editor.Razor` assembly to contain Visual Studio platform agnostic info.
- Added a new `Microsoft.VisualStudio.Editor.Razor.Test.Common` project to be the centerfold for all VisualStudio agnostic test pieces.
- Added a `Microsoft.VisualStudio.Editor.Razor.Test` project and pulled in LanguageService test files into the the Editor.Razor.Test project to correspond to their movement in the src project.
#1690
This change adds an actual background worker for listening to project
change notifications and starts sending updates when the project's razor
dependencies change.
I had to do a litle surgery to get things working. There were plenty of
small bug fixes.
Additionally I got rid of the WeakReferences for tracking listeners. I
was seeing TextBuffers hanging around in VS longer than I expected and
the WeakReferences weren't getting cleaned up. I think it's better that
we just track the lifetime.
I've stripped out some of the dead code and complexity from the document
tracker in an attempt to simplify it. I will bring this back as part of
the multi-targeting work.
This enables the tracking of events that change the 'razor' state of a
document that's open in the editor.
Also fixed a crash that can occur when creating a new project with the
Razor Info window open.
- Added `ILanguageServiceFactory` types for all serviceable contracts.
- Maintained binary compatibility by copy/pasting existing services into a Legacy folder.
- Added a Workspaces.Test project since their implementations moved.
- Updated binary incompatible version of `RazorSyntaxFactsService` to not depend on VisualStudio. Added an extension type to the VS.LanguageServices.Razor project to enable easy-access from VisualStudio.
Below on refers to the binary incompatible copies.
Core services that were **entirely** moved from VisualStudio.Razor => Razor.Workspaces are as follows:
- `RazorSyntaxFactsService`, this included mutating the API to not depend on VisualStudio and moving some primitive types such as `AcceptedCharacters`.
- `TagHelperCompletionService`
- `TagHelperFactsService`
These all have a `ServiceLayer` of `Editor`.
Bits that were partially moved:
- `RazorTemplateEngineFactoryService`. The Default implementation and its corresponding factory still live in VisualStudio.Razor. This way Razor.Workspaces can get by without a reference to Mvc.Razor.Extensions.
- `ITagHelperResolver` used to exist in VisualStudio.Razor. Removed the type and replaced its usage with the already-existing `TagHelperResolver` type in Razor.Workspaces. Both contracts were nearly identical.
These all have a `ServiceLayer` of `Default`.
#1260
Also did some spring cleaning on redundent references in the language
services package.
Note that the 'immutable' packages are now totally redundant with
Shell.15.0. You're supposed to use one or the other. Since our minimum VS
is 15, I just went with shell 15.0.
Now the VSIX project doesn't have many references in it.
- Replaced the magic strings with extension methods that produce the same behavior as the string keys did.
- Added tests to validate new extension methods.
#1307
This is a MEF service that can actively or passively track open ITextViews
and give us information about the Razor initialization state and eventing
when it changes.
The purpose of this is to act as a bridge between the VS mef world and the
roslyn world.
For now this doesn't do any passive tracking of Razor documents, it's only
on demand. That means it will only be initialized and used right now when
you are using the Razor developer tools. This is just to reduce our risk,
it's not ideal to ship code in VS that's doing something without anyone
looking at the result.
Nate McMaster
Pranav K
Ryan Nowak
N. Taylor Mullen
Ajay Bhargav Baaskaran
Nate McMaster
Ryan Brandenburg
Mike Harder