- Removed TaskHelper and refactored with ClosedGenericMatcher
- Removed TypeHelper
- Moved custom encodings to InputFormatter
- Moved ObjectToDictionary to PropertyHelper
- Removed respective tests and test projects
- Could not add tests to validate the full TagHelperDescriptorFactory.CreateDescriptors => TagHelperUsageDescriptors due to how the runtime loads assemblies (does it in memory without XML).
- Added serialization tests to include TagHelperUsageDescriptors.
- Updated existing tests to use new TagHelperDescriptor/TagHelperAttributeDescriptor constructors.
#352
- Added TagHelperUseageDescriptor and associated factory for the TagHelperDescriptorFactory to utilize.
- TagHelperUseageDescriptors are only created during design time.
- CoreCLR is not supported for XML documentation resolution for now. Can revisit this later when we have better tooling integration with CoreCLR.
#352
This is some low hanging fruit for reducing the number of resolves we have
per request.
DefaultHtmlGenerator: Lots of these are created by RazorPage. It needs
IUrlHelper, so scoped is the best we can do for now. For an example, on
the front page of our sample, 48 of these are created for each request.
48! This takes it down to 1-per-request.
JsonResult: Again, multiple created per request (12 for the sample). This
class is totally stateless, so we can get down to 0-per-request.
DefaultViewComponentInvokerFactory: Same story as JsonResult.
DefaultObjectValidator/MvcMarkerService/DefaultFilterProvider:
these are stateless and pretty much guaranteed to be used by every request.
Getting them off the table.
- Duplicate TagHelper bound attributes used to be ignored entirely; they now flow to the output as if they were unbound.
- Added code generation test to verify duplicate attributes. Added runtime and design time versions.
- Updated existing tests that happened to have duplicate bound attributes.
#418
- TagHelper attributes that have expressions intermingled within them (resulting in Block elements) resulted in Spans in the attribute being falsely marked as SpanKind.Markup.
- Updated tests to account for new SpanKind.Code behavior.
- Added complex scenario to validate SpanKind.Code is flowed through to surround attributes.
#387
- was trying out rules matching frequest PR comments (then)
- did a manual scan to find new instances of same issues
- "" -> `string.Empty`
- `String` -> `string` and similar
- fill empty XML doc elements
- ignored `JsonPatchDocument<TModel>`; just too many empty elements
- corrected missing / extra / out-of-order `<param>` descriptions
- `xml-docs-test` detects incorrect external references but not these local issues
- #1514
- refactor `RazorCompilationService` to allow a test subclass that normalizes Razor file line endings
- add `TestRazorCompilationService` to `RazorPageExecutionInstrumentationWebSite`
- adjust line endings to match in `RazorPageExecutionInstrumentationTest`
- add `ignoreLineEndingDifferences: true` to `Assert.Equal()` calls
- responses on Windows can have a mix of line endings
- `git config` setting affects line endings in .cshtml (and baseline) files
- however MVC and Razor mix `Environment.NewLine`s into HTTP responses
- update `PrecompilationTest` to split response regardless of line endings
- update `ResourceFile` to normalize all source file streams to LF only
- ensures consistent checksums and line mappings
- change `MvcRazorHostTest` to expect new line mappings
- recreate baseline files to expect new checksums and literal line endings
- use verbatim strings in affected tests
- careful use of `Environment.NewLine` in expectations is now just noise
nits:
- add doc comments in `RazorCompilationService`
- correct `TagHelpersTest` name to match containing file
- avoid incorrect `using` removal when `GENERATE_BASELINES` is not defined
- remove unnecessary `ResourceFile` normalization of output files