* 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
* Implement IDisposable for derived types for WebApplicationFactory<T>
Add a protected Dispose method and a finalizer to WebApplicationFactory<T> for use in classes that derive from it and want to dispose of their own resources.
Resolves#7631.
* Address review feedback
Only dispose of fields if disposing is true.
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.
- 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
- #6662
- users can now provide a `name` or `data-valmsg-for` attribute to avoid `ArgumentException`s
- affects `<input>`, `<select>`, `<textarea>` elements and validation message `<div>`s
- remove `fullName` check in `DefaultHtmlGenerator.GetCurrentValues(...)` entirely
The new workaround is _not_ identical to changing `ViewData.TemplateInfo.HtmlFieldPrefix`
- does not change where expression values are found in `ModelState` or `ViewData`
- likely needs to be combined with additional workarounds i.e. for advanced use only
nits:
- clean up some excessive argument naming; add a few missing argument names
- take VS suggestions in changed classes e.g. inline a few variable declarations
- clean up some test data
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
- #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
- 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`.
Related to issue [Fixes#6858] Changes to MvcOption's settings (SuppressInputFormatterBuffering & AllowBindingUndefinedValueToEnumType) are not taking affect
* Amend rfc3339 formats to work with all localizations
Changed time separator ":" to "\:" to prevent it from being substituted with a localized separtor. For example in it-IT locale, datetime-local was formatted as 2017-11-19T22.52.29.223 instead of correct format 2017-11-19T22:52:29.223
Changes:
- Remove floating versions
- Disable myget feeds during a Universe build
- Use package-specific MSBuild variables. Pattern = `packageId.Pascalize() + "PackageVersion"`, with a few exceptions.
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.
* Detect a ConfigureDefaultBuilder static method on Program.cs of the test site
and use it to initialize the IWebHostBuilder instance that we configure for testing.
* Make use of the new service configuration extensibility points in Hosting to override
services for testing.
* Get rid of MvcWebApplicationBuilder and move MVC specific methods into extension methods.
- cherry-picked from 7e4a8fe in dev
- #6648
- a different take on #4871
- `DateTime` can also round-trip `DateTimeKind.UTC` with `[DataType("datetimeoffset")]` or `[UIHint("datetimeoffset")]`
- since they're now handled differently by default, add more `DateTime` tests
- expand tests involving `Html5DateRenderingMode.CurrentCulture`
nits: make VS-suggested changes to files updated in this PR
This puts a de-facto metadata approach in the box to declare
unambiguously 'Hey, I am an API!'.
I think this is worth us doing at this point because I haven't really
seen anyone in the community running with targeting conventions at
equivalence classes of controllers.
Now that we're putting API-specific, opinionated behaviors in the box,
we need to away to make it opt-in and declarative.
* Introduce ProblemDescriptionAttribute to enhance some 4xx messages and produce better API description.
* Introduce IErrorDescriptionProvider to modify the shape of error response.
Fixes#6785, Fixes#6786
Pranav K
Brecht Carlier
Ryan Brandenburg
Nate McMaster
Kiran Challa
Nisha Kaushik
Pavel Krymets
Sébastien Ros
Jass Bagga
Ajay Bhargav Baaskaran
Javier Calvarro Nelson
Doug Bunting
Martin Costello
flash2048
Kristian Hellang
Ryan Nowak
N. Taylor Mullen
hede
Ajay Bhargav Baaskaran
Rob Ward
Charlie Daly
Artak Mkrtchyan
Fabien Lavocat
Artak Mkrtchyan
John Luo
Hao Kung
ASP.NET CI
Jeremy Skinner
avertes
Steve Sanderson
Nate McMaster
Dale Palmer
Doug Bunting
Kristian Hellang
Meir017