The RazorProject implementation used by MVC at runtime has a constructor
that takes an IFileProvider (used by tests). This causes ambiguities
when a user registers an IFileProvider in DI.
Cleaning up tests to use a mock instead of the file provider directly
If you give ModelExpressionProvider a lambda with a private property
you'll end up here. This wasn't common before, but it seems like users
are more likely to try it with pages.
Model Metadata and Model Binding don't handle private properties, so
supporting it in Model Expressions seems less than useful.
This isn't a breaking change because this case would have resulted in a
null-ref. Addresses #6400
- #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
* Replace ConnectionContext with HubConnectionContext
- The SocketDelegate implementation owns the transport pipe,
it's a single producer single consumer model. SignalR needs to support
multiple producers so that broadcast, return values and sending to individual
connections works. This change introduces a multi producer channel that is used
by all producers to copy data to the transport safely. This will make the move
to pipelines easier.
- Prior to this imported `@page` directives would flow through the Razor system without error. This resulted in inconsistent behavior between MVC and Razor. Now, imported `@page` directives result in diagnostics on the page directive node.
- Added two tests to verify that we still treat views with imported page directives as Razor pages BUT we also log a diagnostic on the page directive node.
- Renamed the `ViewComponentDiagnosticFactory` class to `RazorExtensionsDiagnosticFactory` so it can be used for more than just view component diagnostics. This way we can ensure that our diagnostics don't end up overlapping.
#1503