* 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
Allow properties on controllers, Razor Page and Razor Page models annotatted with [ViewDataAttribute]
to populate ViewDataDictionary
Fixes https://github.com/aspnet/Mvc/issues/6525
- #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.
* 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.
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.
- #5822
- update `Microsoft.AspNet.WebApi.Client` package version
- remove remaining few `$(PackageTargetFallback)` settings
- remove .NET Standard-specific files
- they duplicate what Microsoft.AspNet.WebApi.Client now provides
- necessary only if cross-compiling a PCL version of the WebApiCompatShim
- add type forwarding for the removed `public` types
- reenable .NET Framework WebApiCompatShim tests
- add breaking change record for `MediaTypeFormatterMatchRanking` value change
- version of this type in the shim lacked the `MatchOnRequestWithMediaTypeMapping` value
- This functionality can be disabled by setting the `Switch.Microsoft.AspNetCore.Mvc.AllowJsonHtml` switch in an app.config.
- Updated tests to react to this new behavior.
- Exposed a new `PublicSerializerSettings` property on `JsonOutputFormatter` so we can accurately copy settings from the used output formatter in `JsonHelper`.
Kiran Challa
Pranav K
Javier Calvarro Nelson
Doug Bunting
N. Taylor Mullen
Ryan Nowak
Ryan Brandenburg
Jass Bagga
Artak Mkrtchyan
Ajay Bhargav Baaskaran
Hao Kung
ASP.NET CI
Nate McMaster