This change introduces a service facade for creating the application
model, running conventions, validating the result, and flattening the
model.
This is used in the ControllerActionDescriptorProvider and provides the
existing functionality for now. The ControllerActionDescriptorProvider
will process the results and turn each 'flattened' model into a single
action descriptor.
The next change will introduce another consumer of this service, that
turns the 'flattened' model into an EndpointModel so that it can be
exposed via Endpoint Routing's convention system.
---
The main considerations here:
The flattening semantics of application model are pretty complicated :(
The validation that CADP does is actually pretty in depth and might be
really low value... Errors with writing route templates do happen, and
those will be caught by the routing system eventually.... Errors with
duplicate route names are similar... Errors with 'mixed' attribute and
conventional routing are not at all common. I don't think I've ever seen
an issue get filed about this. I did the work to port all of this stuff
forward but I'm not totally sure it's valuable - however, I don't really
want to make an argument for its removal. These are just some random
thoughts to keep in mind if you're reviewing this 👍
* React to Razor.Design package removal
* Remove references to packages (Razor.Design, Razor.Extensions) solely used to bring in compiler \ targets
* Target netcoreapp3.0 in samples and tests to allow Sdk to infer values
* Cleanup InferParameterBindingInfoConvention
* Infer BindingSource for collection parameters as Body. Fixes https://github.com/aspnet/Mvc/issues/8536
* Introduce a compat switch to keep 2.1.x LTS behavior for collection parameters
* Do not infer BinderModelName in InferParameterBindingInfoConvention
* Convert `RouteValueDictionary` values to `string` using `CultureInfo.InvariantCulture`
- #8578
- user may override this choice in one case:
- register a custom `IValueProviderFactory` to pass another `CultureInfo` into the `RouteValueProvider`
- values are used as programmatic tokens outside `RouteValueProvider`
nits:
- take VS suggestions in changed classes
- take VS suggestions in files I had open :)
- avoid "Skipping test case with duplicate ID" messages
- xUnit gets confused when `[Theory]`s are overridden
- avoid "falling back to single test case" messages
- fix inspired by aspnet/SignalR#1820
This doesn't really accomplish our goals for 2.2 - I don't have a clear
scenario where I would tell a developer to use this VS something else.
Will reevaluate in 3.0
To enable custom handling of antiforgery validation failures, use an
`AntiforgeryValidationFailedResult` which is just a `BadRequestResult`
but allows to be identified explicitly inside always-running result
filters using the `IAntiforgeryValidationFailedResult` marker interface.
Nate McMaster
Ryan Nowak
Pranav K
Ben Adams
Alexej Timonin
Doug Bunting
Javier Calvarro Nelson
James Newton-King
Doug Bunting
Patrick Westerhoff