* Change DefaultApiConventions
* Introduce attributes for matching by name and type.
* Move discovery of ApiConventionAttribute to ApiBehaviorApplicationModelProvider. This is required
for us to detect during startup if the convention is incorrectly authored.
* 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
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
* 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 was in the wrong place - JSON formatters have their own options
type already.
Moved the option to MvcJsonOptions and updated the naming + defaults to
reflect our plan.
Also did a bunch of general cleanup on these tests, which were a bit
sloppy.
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
Updated the naming to follow guidelines, and set the default for 2.0
apps to false. Note that I inverted the naming, which means that I had
to invert the logic in a few places.
* [Design] Compatibility switches
This introduces a pattern for versioning breaking behaviour changes in
minor releases of MVC.
The general plan is that application developers choose a release version
(2.0, 2.1, Latest) as their baseline which determines the effective
'defaults' for some options. Anything the developer sets explicitly is
an override and always wins.
Then we add a version setting to the template to point to the current
release.
This allows us to be progressive with fixing issues and improving areas
that don't work well, but offers the developer some choice about when to
adopt new behaviours. In effect, we separate new behaviours from the
libraries that develiver them. Apps can update the version, and then opt
in to new behaviours as a separate change.
* Be more american
* improve docs, add example
* Fix visibility
* Fix broken test
* Add test
* Docs!
* The rest of the tests
* fix example
* Adding docs
* PR feedback
Pranav K
Kristian Hellang
Ikebe Shodai
Kiran Challa
James Newton-King
Ryan Nowak
Justin Kotalik
Doug Bunting
Kiran Challa
Ryan Nowak
Hao Kung
kishanAnem
John Luo
Kristian Hellang
Artak Mkrtchyan
Javier Calvarro Nelson
Jass Bagga
Hao Kung
ASP.NET CI