* Fix client validation for record types
Server validation for record types uses metadata from parameters
when validating record type properties. However client validation
does not use the parameter to harvest client validation attributes.
In the absence of this change, validation on parameters would require server
round trips which is unexcepted and not at parity with validation applied
to properties on regular classes or record types.
Validation experience with record types is subpar and requires server
round trips.
No. This feature is new to 5.0.
Low. The change is isolated to record types and does not affect other code paths. We have
unit and functional test coverage to verify this change.
* Correctly dispose app after use
* Create data sources "per router" instance.
* Make a global shared order sequence "per router" for conventional and
controller and page routes.
* Create DynamicControllerEndpointSelector and DynamicPageEndpointSelector
instances per data source.
* Guard against client disconnect exceptions that appear when performing ReadFormAsync
Reading the request body may throw an exception. This change adds some extra guards
for this and presents this as a 4xx response rather than a 5xx response.
* Add some tests
* Fixup test
* Add support for binding record types
* PR feedback
* PR changes
* Changes per PR comments
* Changes per PR comments
* Update src/Mvc/Mvc.Core/src/Resources.resx
* Apply suggestions from code review
* Add some more tests
* Undo blazor.server.js changes
* Fixup test
* Apply suggestions from code review
Cleaned up error messages. Thanks @jamesnk, I totally overlooked the content.
Co-authored-by: James Newton-King <james@newtonking.com>
Co-authored-by: Javier Calvarro Nelson <jacalvar@microsoft.com>
Co-authored-by: James Newton-King <james@newtonking.com>
* nit: Remove useless `$(HasReferenceAssembly)` settings
- set in /Directory.Build.targets
- `true` only in `$(IsAspNetCoreApp)` projects
* nit: Remove useless `$(CompileUsingReferenceAssemblies)` settings
- no current versioning differences between ref/ and src/ assemblies when targeting default TFM
* Add more `$(GenerateDocumentationFile)` settings
- increases the number of generated doc files, mostly without problems
- !fixup! correct typo in `DebugProxyHost` doc comments
- was not generating a doc file before
- remove previous (ineffective) src/Components/Directory.Build.targets setting
- nit: remove a duplicate `$(GenerateDocumentationFile)` setting
* nit: Remove useless `$(IsPackable)` settings
- only analyzers and implementation projects are packable by default
- main use case for explicit setting is projects shipping only in shared framework
- conditional setting in src/Mvc/Directory.Build.props just subset logic in /Directory.Build.targets
* nit: Remove useless `$(IsProjectReferenceProvider)` settings
- only implementation projects are providers by default
* nit: Remove useless `$(IsTestAssetProject)` settings
- set in src/Mvc/test/WebSites/Directory.Build.props
* !fixup! Looks like `InProcessNewShimWebSite` must compile w/o ref/ assemblies
- restore `$(CompileUsingReferenceAssemblies)` in this one project
Validation attributes such as a CompareAttribute require a container to be configured in ValidationContext. This change
configures uses the controller or page handler instance that the property is being bound on when binding top-level properties.
Fixes https://github.com/dotnet/aspnetcore/issues/4895
* Introduce ValueProviderException analogous to InputFormatterException
* Record ValueProviderException as a model state error
* Fixup bug in reading ProblemDetails \ ValidationProblemDetails using the converter
Fixes https://github.com/aspnet/AspNetCore/issues/10291
* [Blazor] Allows multiple components as entry points
* Removes all overloads that register a component statically with aborts
selector.
* Updates render component to have a RenderMode parameter that indicates
how the component must render. Valid values are Static, Server, and
ServerPrerendered.
* When using Server or ServerPrerendered we emit marker comments into
the page that are later used by blazor.server.js to bootrstrap a
blazor server-side application.
Fixes: #12553
This change renames all of our browser/DOM specific types from
`UIFooEventArgs` to `FooEventArgs` and puts the in the `.Web` namespace.
In addition to this, we're moving `EventHandlers` and `BindAttributes`
to the same. This has the impact of scoping the mappings those classes
provide based on the `.Web` namespace.
This means that we now expect `.Web` to be present as a using in
basically all contexts for a browser-based Blazor app. Updated
templates, samples and tests. I'll also need to update about a million
tests in the compiler codebase.
I've logged https://github.com/aspnet/AspNetCore.Docs/issues/13832 to
track the docs and release notes part of this work.
* Ensure JsonSerializer always HTML encodes output.
* Update JsonOptions.JsonSerializerOptions to use encoder scheme that does not encode non-ASCII
characters by default. This makes the encoding comparable to Json.NET's defaults
* In SystemTextJsonHelper, ensure that the content is always HTML-encoded
* Unskip skipped test
Fixes https://github.com/aspnet/AspNetCore/issues/9946
Fixes https://github.com/aspnet/AspNetCore/issues/11459
* Rename IUriHelper -> NavigationManager
- Remove IUriHelper interface
- Rename to NavigationManager
- Remove all traces of old naming
There's no functional or design change in this commit - just removing
all traces of the old name. The next few iterations will try to improve
the design.
* Minor API tweaks to NavigationManager
Making Initialize protected causes problems because right now the
server-side code needs to deal with one of two different
implementations, hence an exchange type is used. I followed the same
pattern that was used for auth for symmetry but I have some *cool*
thoughts.
- We can remove this when we remove stateful prerendering
- I have another idea to banish this pattern to the land of wind and
ghosts
If this ends up sticking around longer than a week in the code, lets
discuss other ideas and try to improve the pattern.
* Use hub method for server-side navigation
* Get rid of async local
* Add hub method test
* Misc bikeshedding
* Update src/Components/Server/src/Circuits/DefaultCircuitFactory.cs
Co-Authored-By: campersau <buchholz.bastian@googlemail.com>
* PR feedback
Fixes: #12245Fixes: #12630
This change removes stateful pre-rendering from Server-Side Blazor. This
means that when you render a component during the initial HTTP request,
we we will no longer preserve the component instances and their
parameters. While this feature was useful, it cause serious scalability
concerns.
This means that it will now be required to register "entry-point"
components in startup similar to client-side Blazor.
Fixes: #12548
Renaming properties to drop 'Content' as a suffix. We haven't been
consistent in using this, and we're removing it instead of adding it
elsewhere.
Adds infrastructure for a common IRouter-based pattern. In this pattern,
an extender subclasses Route to post-process the route values before MVC
action selection run. The new infrastructure duplicates this kind of
experience but based on endpoint routing.
The approach in this PR starts at the bottom... meaning that this is the
most-focused and least-invasive way to implement a feature like this.
Similar to fallback routing, this is a pattern built with matcher
policies and metadata rather than a built-in feature of routing.
It's valuable to point out that this approach uses IActionConstraint to
disambiguate between actions. The other way we could go would be to make
the *other* matcher policy implementations able to do this. This would
mean that whenever you have a dynamic endpoint, you will not by using
the DFA for features like HTTP methods. It also means that we need to go
re-implement a bunch of infrastructure.
This PR also adds the concept of an 'inert' endpoint - a non-Routable
endpoint that's created when fallback/dynamic is in use. This seems like
a cleaner design because we don't start *matching* RouteEndpoint
instances for URLs that don't match. This resolves#8130
* Make JSON case-insensitive
Fixes: #10724
The rationale for this change is that existing .NET client code for the
most part uses JSON.NET with its default settings (preserve property
casing). This includes the WebAPI client - which we're encouraging
everyone to use. It's not really reasonable for us to break everyone
using webapi client.
* Make separate options and add extension method
* fixit
* fix build
* fix text
* Adds inferred [Required] for non-null ref types
Follow up from #9194
This change adds the automatic inference of [Required] for non-nullable
properties and parameters. This means that if you opt into nullable
context in C#8, we'll start treating those types as-if you put
[Required] on them.
This provides a nice invariant to rely on, namely that MVC will honor
your declared nullability contract OR report a validation error. This
reinforces the guidance already published by the C# team for using
POCOs/DTOs with nullability. See
https://github.com/aspnet/specs/blob/master/notes/3_0/nullable.md for my
analysis on the topic.
* preemptively fix PR feedback xD
* PR feedback and functional test
* more
* Fix test failures
* fix
* more
* Do a barrel roll
Pranav K
Javier Calvarro Nelson
dotnet-maestro[bot]
Ryan Nowak
Ajay Bhargav B
Steve Sanderson
Doug Bunting
John Luo
Ryan Brandenburg
Ryan Nowak
N. Taylor Mullen
Chris Ross
Martin Costello
Hao Kung
Artak