* 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.
- #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
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.
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
FileStreamResultExecutor creates a logger for VirtualFileResultExecutor. I suspect this is a copy-and-paste error and creating one for FileStreamResultExecutor was intended instead.
- 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
- #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`
Jass Bagga
Rob Ward
Pranav K
Artak Mkrtchyan
Kiran Challa
Javier Calvarro Nelson
John Luo
Ryan Nowak
Doug Bunting
Hao Kung
ASP.NET CI
Jeremy Skinner
Steve Sanderson
Nate McMaster
Dale Palmer
Sébastien Ros
Doug Bunting
Kristian Hellang
Charlie Daly
Christiaan
Adrian Wright
bchavez
Nate McMaster
Hao Kung
Ryan Brandenburg
Henk Mollema