- Make `RazorProjectEngine` call paths for all feature registrations.
- Add `DefaultMvcImportFeature` for latest and 1.X MVC.
- Ported `AddTargetExtension` and `AddDirective` to `RazorProjectEngineBuilderExtensions`.
- Added tests and a test file system project type.
- Moved obsolete `IRazorEngineBuilder` methods to the bottom of each file. Will actually obsolete the methods once `RazorProjectEngine` is working end-to-end.
#1828
Using the MVC view engine convention for identifiers seems to make the
most sense, and we already use that convention for RazorProject so I
guess we're stuck with it.
* Add metadata to Razor
This PR introduces standard metadata to Razor. This change begins to
formalize the contract between generated code produced by Razor and
runtimes that want to load and interact with this code.
This is a step on making MVC a 'plugin' to Razor rather than the only
possible implementation. Since we're doing MSBuild work - this is the
right time to designate the current interaction between Razor and MVC as
'legacy' and move forward.
Additionally, we need the source thumbprinting to make re-compilation of
Razor a thing.
-----
Also I noticed that our source document doesn't expose the hash
algorithm by name. We really should have this, so I added it and
hardened the code that deals with checksums in c# generation.
This uses a feature of KoreBuild which will select PackageReference
versions based on a lineup file. This helps unify versions between repos
and helps us ensure we are consistent across multiple components.
- Changed `SectionDirectivePass` to move non-token body nodes from the original `DirectiveIntermediateNode` to the `SectionIntermediateNode`. By doing this there's no longer dual references of `SectionIntermediateNode` bodies.
- Added MVC tests for current and 1_X extensions.
#1614
- Added 1_X src project for multitargeting
- Added 1_X test project for multitargeting
- Added 1_X test MvcShim for multitargeting
- Make section directive generate the correct code the appropriate version
- Added another sln
We don't really want to ship what we have as a contract. As an emergency
measure we are making it into internal extension methods so we can have
a do-over in 2.1.
- The `@page` directive will now look for malformed directives and treat a view as a Razor page based on the existence of the malformed directive.
- Updated the `PageDirective` type to contain a reference to its responsible directive node.
- Added unit tests to validate malformed directives were picked up accordingly.
- Updated code generation test baselines to reflect the new malformed directive understanding.
#1448
- Prior to this imported `@page` directives would flow through the Razor system without error. This resulted in inconsistent behavior between MVC and Razor. Now, imported `@page` directives result in diagnostics on the page directive node.
- Added two tests to verify that we still treat views with imported page directives as Razor pages BUT we also log a diagnostic on the page directive node.
- Renamed the `ViewComponentDiagnosticFactory` class to `RazorExtensionsDiagnosticFactory` so it can be used for more than just view component diagnostics. This way we can ensure that our diagnostics don't end up overlapping.
#1503
- Rename `CSharpRenderingContext` => `CodeRenderingContext`.
- Rename `CSharpCodeWriter` => `CodeWriter`
- Rename `BasicWriter` => `IntermediateNodeWriter`
- Rename `...BasicWriter` => `...NodeWriter`
- Made `CodeRenderingContext` a public abstract API. Left temporary TagHelper pieces in the class since these will be removed soon.
- Moved several `CodeRenderingContext` methods into extension methods. These make use of the Items collection.
- Moved the reporting of missing code target extensions into the `ExtensionIntermediateNode`. This is the integration point of `CodeTarget`s and `CodeRenderingContext`s; therefore, it made more sense existing there.
- Left SetRenderChildren/SetRenderNode as extension methods due to how they're wired up. Aka, to create a `CodeTarget` you need a `CodeRenderingContext`... To Create a `DocumentWriter` you need a `CodeTarget`... To set the render methods on the context you need a `DocumentWriter`.
- Updated tests to utilize the new code renering constructs.
- Moved code generation testability features from `CSharpLoweringPhase` to the `CodeRenderingContext.Items`.
#1043
instead of methods
More polish to the tag helper descriptor builders.
- Expose underlying builders as getter only list
- Added AsDictionary() extension method to BoundAttributeDescriptorBuilder
- Expose diagnostics as RazorDiagnosticCollection
- Got rid of Require** prefix in TagMatchingRuleBuilder
- Workaround issue aspnet/Razor#1492 by copying the test descriptor
extensions
This makes it possible to use another 'kind' of tag helpers, which isn't
possible today.
This also further decouples the tag helper api surface from the default
implementation.
VCTH now have their own 'kind'.
Also improved generation of display names and error messages where it
was coupled to the type name.
- Updated integration code gen and IR bits to reflect new directive usage.
- Updated existing unit tests that happened to test directives in code blocks to now test what happens when they exist at the document level. Being inside of a code block is now invalid and we have separate tests for that scenario.
#1376
- Added error case that enforces whitespace in between directive tokens.
- Upon encountering invalid directive tokens/states we bail out of parsing and log an appropriate error.
- Raised directive parse errors to the IR layer. This is slightly hacky given the parsers limitations; we swap out the error sink temporarily to capture all directive parser errors and then shove the errors collected onto the directives chunk generator.
- Added a `MalformedDiretiveIRNode` and corresponding pass to represent directives that are in an invalid state. Chose to not take the path of using the default `DirectiveIRNode.Diagnostics` member to enable users who are extending directives to only ever have to work with "valid" directives. If they want to work with malformed directives they can search the IR document for their malformed counterpart and handle it separately.
- Updated existing test expectations
- Removed some existing tests that were no longer valid (we don't call into user code if a directive is malformed).
#1173
N. Taylor Mullen
Ryan Nowak
Pranav K
Ajay Bhargav Baaskaran
Nate McMaster
Nate McMaster
Ryan Brandenburg