We want to have a way to specify the taghelper descriptors and imports to use while
processing a specific document.
- Added an overload to Process and ProcessDesignTime to take in a list
TagHelperDescriptors and a list of imports
- Added the corresponding CreateCodeDocumentCore overload
- Added GetTagHelpers and SetTagHelpers extension methods for
CodeDocument
- Added the necessary plumbing to use the taghelpers from the
CodeDocument when available and fallback logic.
- Added DocumentImportsTracker and updated background code generation
logic to use the new overload
- Added/updated tests
The hash code implementation here is exhaustive when it doesn't need to
be. Slimming this down to a much more reasonable set of things for perf
reasons.
The project snapshot now maintains a RazorProjectEngine as well as set
of Tag Helpers that are known for that snapshot.
Pivoted some more services to be snapshot-centric.
Also added the ability to track .cshtml documents to the project system.
For now most components just ignore document changes.
This change will allow someone extending Razor to use generic type
parameters in generated classes.
There's no user-level extensibility provided here yet, as in there is no
language support for adding type parameters.
* Merging changes (from dev branch; doing manually to squash them really)of HTML Parser to be aware of HTML Comments so TagHelpers don't complain about comments as content.
- For older version of Razor the HTML comments will be complained about by TahHelperRewriter
- RazorParserFeatureFlags tests now ensure that AllowHtmlCommentsInTagHelpers is true in 2.1 version and false in older versions
- Added extra test for IsHtmlCommentAhead to make sure Razor code transition is allowed in comment tag
- Moved the unallowed html comment ending to a static array.
Since the default tag helper provider is used by MVC then MVC should
include it. Now that Blazor is in the mix we shouldn't include it for
all configurations.
- Existent imports are imports that have content that contribute to the processing of a Razor document. Prior to this we had a legacy expectation that code documents had empty markers in them for all of their import locations. This proved troublesome when cross-referencing files that had file paths and were supposed to be existent but weren't in metadata. Now that we have a project engine with a de-coupled import feature we can rely on the import feature for finding all locations of important files and then strip out any non-existent items.
- Strings here was important because any import added to the system dynamically needs to eventually make its way back to being a project item. With strings we can state that they do exist (have content) but do not have any file paths associated.
- Updated all call sites to use the new AddDefaultImports string based api.
#2080
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.
Ajay Bhargav Baaskaran
Ryan Nowak
Ryan Nowak
N. Taylor Mullen
Pranav K
Ryan Brandenburg
Artak
Artak Mkrtchyan