* This allows specifying all it's dependencies rather than for consuming projects to do this
* Remove unused APIs
* Fix weird downgrade warnings that show up due to P2P references
'ValidationExcludeFilter' -> 'SuppressChildValidationMetadataProvider'
Also moved to .ModelBinding for improved discoverability. There aren't
many reasons user code would have a using for .Validation.
Moves IControllerArgumentBinder and IControllerPropertyActivator into
.Internal. Also renames ControllerArgumentBinder ->
DefaultControllerArgumentBinder for consistency with other controller
extensibility types.
We don't think these are 100% baked for our long term maintenance of the
product, and want to reserve the ability to make changes in the future.
- #4652
- previously ignored for top-level models
- `ModelBinderProviderContext.BindingInfo` is now never `null`
- similarly, use type metadata (as well as parameter info) for `ModelBindingContext.BinderModelName`
- previously ignored when overridden in `ControllerArgumentBinder`
This test was relying on the parsing behavior of QueryString, that it
would omit the key and value when the value is empty. The expectations
weren't consistent with other tests for 'empty' values.
This change simplifies a bunch of code and fits more in line with the
current design of model binding.
Now, a model binder only has to do anything if it was successful.
'return' is enough to indicate failure.
This change just rearranges some code in the argument binder with a mind
towards performance and clarity. We're removing a few Task<T>'s here as
well in certain cases, but not yet all of them. We additionally save a
dictionary in the case where you have bound properties.
Hopefully these changes break the code into more discrete and sensible
units without multiple levels of indirection without abstraction.
- Main 'driver' code
- BindModel
- ActivateProperty
We want this change to avoid MVC eagerly reading the form. This is good
for general perf and also for scenarios where you want read the body
yourself (large file uploads).
We DO have scenarios where you want to configure the value providers
per-request or also to change the limits on the value providers (form) so
it's worth keeping these around on the context.
- #4339: remove non-recommended JSON formatter constructors
- affects `JsonInputFormatter`, `JsonOutputFormatter`, `JsonPatchInputFormatter`
- `JsonOutputFormatter` cleanup also impacts `JsonHelper`
- rename and make `SerializerSettingsProvider` class public; use it as appropriate
- #4409: make `SerializerSetings` properties get-only and `protected`
- affects `JsonInputFormatter`, `JsonOutputFormatter`
Recommended patterns:
- change `JsonSerializerSettings` values in `MvcJsonOptions` for almost all customizations
- find `JsonOutputFormatter` in `MvcOptions.OutputFormatters` when limiting per-result formatters
- start with `JsonSerializerSettingsProvider.CreateSerializerSettings()` when customizing a per-result formatter
This commit introduces application parts as a concept on MVC.
An application part is an abstraction that allows you to expose some
feature or corncern in a way that is decoupled from their underlying source.
Examples of this include types in an assembly, emdeded resources, files on
disk etc.
Application parts are configured during startup by adding or removing them from
the application part manager available as part of IMvcBuilder and IMvcCoreBuilder.
The application part manager provides the ability to populate features from the
list of available application parts by using a list of application feature providers.
Application feature providers are responsible for populating a given feature given a
list of application parts.
Examples of application providers can be a ControllerFeatureProvider
that goes through the list of application parts, sees which one of those parts exposes types,
determines which of those types are controller types, and adds them to a ControllerFeature
that holds a list of all the types that will be considered controllers in the application.
This change no longer suppresses validation for IFormFile and
IFormFileCollection model values. This will allow the use of [Required] on an
IFormFile model, or a custom attribute for validating IFormFileCollection.
These types already have ValidateChildren = false, so we don't recurse
into them.
This change separates model binding into IModelBinderProvider (decides
which binder to use) and IModelBinder (does binding). The
IModelBinderFactory is a new services with coordinates the creation of
model binders.
- #3482
- see new tests; many failed without fixes in the product code
- add support for binding `IFormFileCollection` properties
- make `FormFileModelBinder` / `HeaderModelBinder` collection handling consistent w/ `GenericModelBinder`++
- see also dupe bug #4129 which describes some of the prior inconsistencies
- add checks around creating collections and leaving non-top-level collections `null` (not empty)
- move smarts down to `ModelBindingHelper.GetCompatibleCollection<T>()` (was `ConvertValuesToCollectionType<T>()`)
- add `ModelBindingHelper.CanGetCompatibleCollection()`
- add fallback for cases like `public IEnumerable<T> Property { get; set; } = new T[0];`
- #4193
- allow `Exception`s while activating collections to propagate
- part of #4181
- `CollectionModelBinder` no longer creates an instance to check if it can create an instance
- not a complete fix since it still creates unnecessary intermediate lists
nits:
- correct a few existing test names since nothing is not the same as `ModelBindingResult.Failed()`
- remove a couple of unnecessary `return` statements
- correct stale "optimized" comments
- explicit `(string)`
- aspnet/Coherence-Signed#187
- remove `<RootNamespace>` settings but maintain other unique aspects e.g. `<DnxInvisibleContent ... />`
- in a few cases, standardize on VS version `14.0` and not something more specific
Pranav K
Kiran Challa
Ryan Brandenburg
Doug Bunting
N. Taylor Mullen
Ryan Nowak
Sebastien Ros
Pavel Krymets
jacalvar
David Fowler