* Allow controller and Razor Page models to be annotated with BindPropertiesAttribute
* Disallow BindPropertyAttribute from being declared on types.
* Do not allow arbitrary binding attributes to be applied to Razor Page models.
Fixes#7686
- #7595
- #7595 relates to #7350 but does not have the same root cause
- did _not_ revert the src changes in #7350 fix (d995b0418a)
- make non-`[Obsolete]` `ModelAttributes` constructor overload `internal`
- should generally use `static` methods and not any constructor
- change some unit tests to use `[Obsolete]` constructor overloads (with suppressions)
- fix test `ParameterBinderExtensions` to use current `ParameterBinder.BindModelAsync(...)` overload
- found some tests updated `IModelMetadataProvider`, `MvcOptions`, etc. instances but didn't register them in DI
- extend `ModelBindingTestHelper` and `ModelBindingTestContext`
- reorder some tests to use correct `MvcOptions` and `IModelMetadataProvider` everywhere
- fixes above issues
nits:
- take a few VS suggestions
- remove an old comment indended only for PR "Reviewers:"
- #7423
- retry failed inner bindings with alternate syntax in `ModelStateDictionary`
- use property syntax if first attempt tried index syntax and visa versa
- instantiate `ShortFormDictionaryValidationStrategy` with full `ModelState` keys
- can now provide exact `ModelState` keys that `ModelStateDictionary` used in inner bindings
- normalize model names without a leading period in `JQueryKeyValuePairNormalizer`
nits:
- take a few VS suggestions
This change undoes a breaking change introduced by the 2.1 model
validation changes. Now an implementation of IValidableObject on a
top-level model will be called correctly with the 'empty' prefix instead
of the parameter name.
When fixing this we undid a workaround for another issue.
When validating a parameter that didn't bind we didn't correctly compute
the model name for 'fallback to empty prefix' cases.
(cherry picked from commit 7a1096a72b)
This changes the logic for when we infer [FromRoute] on an action
parameter from *ALL* to *ANY*.
This means that if a parameter occurs in any route on an ApiController,
we will treat it as [FromRoute]. We think this is the best decision
because it's less ambiguous. If a parameter appears in a route, it won't
be eligible to be bound from query. I think that's good.
If for some reason you want this kind of behavior (route or query) then
we suggest breaking up the actions. This isn't very documentation
friendly (swagger) so we don't suggest it.
- #7413 part 2 of 2
- add `ModelMetadata.Name` and `ParameterName`
- use `Name` instead of `PropertyName` in most cases
- update `ModelMetadata.ContainerType` and other property use
- choose using `MetadataKind` almost everywhere; support all possibilties
- usually parameter metadata was possible but not handled
- worst case was one or two potential NREs, especially `ContainerType.*` dereferences
- improve `MvcCoreLoggerExtensions` metadata handling
- add three new debug messages, one for type metadata and two for parameter metadata
- update `ModelMetadata.ContainerMetadata`, `ContainerType` and `PropertyName` doc comments
- no changes needed in Microsoft.AspNetCore.Mvc.ViewFeatures because parameters aren't viewed
nits:
- add missing `TestModelMetadataProvider.ForParameter(...)` method
- remove unused `EmptyModelMetadataProvider` instances in `ModelMetadataTest`
- refactor `ModelValidationResultComparer` out of DataAnnotationsModelValidatorTest`
- take VS suggestions, mostly related to variable inlining and object initializers
This allows the use of custom 'envelope' types like ActionResult<> with
a corresponding API Explorer implementation.
Basically this PR services to decouple a bunch of infrastructure from
ActionResult<>.
- #7413 part 1 of 2
- made all `ModelMetadataProvider` and `ObjectModelValidator`-specific code conditional
- fortunately, `MvcOptions` easy to get; affected code is primarily `internal` or pub-`Internal`
- remove unnecessary `ModelMetadataProvider` use in `ApiBehaviorApplicationModelProvider`
- run integration and functional tests with `CompatibilityVersion.Version_2_1`
- functional test change depends on @javiercn's recent #7541 fix
- remove test code now redundantly turning compatibility switches on
nits:
- correct spelling errors in `CompatibilitySwitch`
- take VS suggestions, mostly in test code
- rename methods in `ControllerBinderDelegateProviderTest` to match current API
- slightly refactor in `ApiBehaviorApplicationModelProvider`
Infers the 'empty' model prefix for complex types that are read from the value
providers. This gives us better defaults when using the parameter object
pattern with respect to swagger/API explorer.
- #7091
- add `IKeyRewriterValueProvider` to remove rewritten keys or value providers containing such keys
- similar to `IBindingSourceValueProvider` except `CompositeValueProvider` keeps non-implementers around
- remove `after.Order == before.Order` special cases
- a premature optimization that could lead to lost inner provider replacements
- rework `EnumerableValueProviderTest` to ease test override in `CompositeValueProviderTest`
- add `EmptyValueProvider` fields to reduce `CompositeValueProvider` allocations
nits:
- remove Linq use in `CompositeValueProvider`
- do not create an unnecessary dictionary in `CompositeValueProvider.Filter(...)` methods
- accept VS suggestions, mostly pattern matching
Ryan Brandenburg
Kiran Challa
Pranav K
Pavel Krymets
Jass Bagga
Doug Bunting
flash2048
Kristian Hellang
Ryan Nowak
hede
Ajay Bhargav Baaskaran