- #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 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.
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.
* 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.
- worst cases were incorrect references in doc comments
- also a few doc comments ended with `..` or `/`
- otherwise, address nits and take VS suggestions
- #7044
- move `IHttpResponseStreamWriterFactory` too
- add breaking change records e.g. for changes to `BodyModelBinder[Provider]` constructors
- these changes relate to previously-"internal" constructors and one property
nits: take VS suggestions for changed files
This issue causes problems with ValueTuple when used across assembly
boundaries between netstandard and net4X when net471 is installed. These
tests fail consistently in appveyor and will fail on any machine with
net471 installed.
- #6596
- better-align this code with `ResourceInvoker.Rethrow()`
nits:
- take VS suggestions in `MiddlewareFilterBuilderTest`
- clean up names like `httpCtxt`
- remove unused `Pipeline2` class
We have all of these executors but they aren't really
documented/supported for extensibility today. This change introduces a
pattern for action result executors so we can make them extensible.
- #6076
- add resources and accessors specifically for the element / parameter cases
- avoid `metadata.GetDisplayName()` where possible
- fill in the `ValidationContext` that `ValidatorObjectAdapter` uses
- e.g. `Validate_NestedComplexType_IValidatableObject_Invalid()` test fails without this
Possible future work:
- improve error message used for `ModelMetadata.IsRequired` elements and parameters
- use something besides the type for `ValidationContext.DisplayName` of elements and parameters
nits:
- trailing whitespace
- use more `out var`
This changeset reckonciles the binding work we did for pages with
controllers.
A quick summary:
- Moves [BindProperty] to the MVC namespace (#6401)
- Makes [FromRoute] and friends behave consistently (#6402)
- Makes [BindProperty] work with controllers (untracked)
Doug Bunting
Kiran Challa
Pranav K
John Luo
Kristian Hellang
Ryan Nowak
Javier Calvarro Nelson
Nate McMaster
Steve Sanderson
bchavez
Nate McMaster
Jass Bagga