Currently MVC is still running the IActionConstraint implementations for
features that we've already moved into the routing layer. This has a
significant perf cost associated with, and so we want to skip it because
it's redundant. However if anyone has implemented their own
`IActionConstraint`-based features, they still need to just work.
This change takes the approach of skipping the action constraint phase
at runtime unless we see something 'unknown'. This is an all or nothing
choice, and will run action constraints if **any** action constraint we
don't special case exists. This is the most compatible behavior (running
redundant constraints) when the application is using constraints that
the developer implemented.
Another approach I considered was to eliminate these constraints as part
of the process of building ADs. I don't think that's ideal because
people have written code that introspects action constraints. We should
consider something like this in 3.0.
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 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.
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
* 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
- Move the Mvc.Performance project from test/ to benchmarks/.
- Remove the Version attribute on PackageReference.
- Add a reference to two PackageLineup's.
- Add snippet to README explaining the additional requirement to run build.cmd /t:restore.
- Add a target to check that packages have been pinned.
- #5502
- support thousands separators for `decimal`, `double` and `float`
- add tests demonstrating `SimpleTypeModelBinder` does not support thousands separators for numeric types
- add tests demonstrating use of commas (not thousands separators) with `enum` values
This doesn't go through the Razor tag helper discovery pipeline because
this can really only ever work for ITagHelper based taghelpers. So
there's really no point in reusing that logic, which would be hard
anyway.
Ryan Nowak
Pranav K
Simon Cropp
James Newton-King
Kiran Challa
ASP.NET CI
Nate McMaster
Justin Kotalik
bchavez
Nate McMaster
Doug Bunting
Jass Bagga
Pavel Krymets
Hao Kung
Ryan Brandenburg