* 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:"
* Disable deps file generation in class library project. This workarounds known issue - https://github.com/dotnet/core-setup/issues/3726
* Update RazorProjectRouteModelProvider to not specify a trailing slash. This produces paths with a single slash as opposed to two slashes messing with route creation.
* React to Microsoft.AspNetCore.Mvc.Razor.Extensions.Reference that shows up in the deps file.
- #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
Allow properties on controllers, Razor Page and Razor Page models annotatted with [ViewDataAttribute]
to populate ViewDataDictionary
Fixes https://github.com/aspnet/Mvc/issues/6525
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`
- The model attribute is used to define any object based model to be passed to a `TagHelper`. It enables scenarios when users want to pass in `new` poco types.
- Added unit tests for the new `ResolveModel` method in `PartialTagHelper`.
- Added a single functional test to verify the end-to-end.
#7374
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.
Some details of this pending discussion, but this is a new 2.1 change
and compatibility switch in the spirit of making pages handler selection
less error-prone.
In particular we don't want anyone to have to define HEAD to do the
trivial thing. This currently routes all 'safe' HTTP methods to the GET
handler and all other HTTP methods to the POST handler.
This is technically not the correct thing to do for OPTIONS and TRACE,
so we might still do something different.
The tests will change a little depending on exactly what we decide to
do, but this is the main idea of the change.
- #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
* Clean up unnecessary workarounds on the build project.
* Remove the need to specify the content root relative to the solution
and use a solution based on an assembly level attribute on the test
assembly created at build time.
* Remove non parameterless constructors.
* Add support for creating specialized factories from the base factory
and keep track of "child" factories for disposal.
* Add support for creating clients that handle cookies and redirects
automatically.
- Updated our consumption of `RazorEngine` and `RazorTemplateEngine` to use `RazorProjectEngine` and its features.
- Updated service registrations to maintain existing services but to also register new ones.
- When moving `RazorViewEngine` to use `RazorProjectFileSystem` I had to add an unused constructor item in order to disambiguate the constructors.
- Updated tests to use `RazorProjectEngine` and `RazorProjectFileSystem`.
#7377
On HtmlHelper<T> we now support contextualizing an instance of
HtmlHelper<TBase> with a ViewDataDictionary<TDerived> in
ViewContext.ViewData.
This can happen in some situations when the model for a RazorPage has
been changed using a page application model convention.
In these cases we just build a new ViewDataDictionary<TBase> and pass in
the TDerived model as an instance.
* Support loading parts through an assembly metadata attribute with a
key of Microsoft.AspNetCore.Mvc.AdditionalReference and a value that
describes the additional assembly to add to the list of parts and
whether or not it should be added by default. The additional reference
can only contain the file name of the assembly and it must be located
side by side with the assembly where the additional reference is
defined.
* Add an AdditionalAssemblyPart application parts to represent parts
that are not part of the original application per se, like precompiled
views.
* Update the ViewsFeatureProvider to search for razor views in the
application part directly instead of trying to load the precompiled
views assembly part.
Ryan Brandenburg
Kiran Challa
Pranav K
Nisha Kaushik
Sébastien Ros
Doug Bunting
Ajay Bhargav Baaskaran
Javier Calvarro Nelson
John Luo
Kristian Hellang
Ryan Nowak
N. Taylor Mullen
Jass Bagga
Charlie Daly
Artak Mkrtchyan
Fabien Lavocat
Artak Mkrtchyan