* Do not perform synchronous writes to the Response TextWriter after a Razor FlushAsync
* Use ViewBuffer to perform async writes to the response when using ViewComponentResult
Related to #6397
Fixes https://github.com/aspnet/AspNetCore/issues/4885
* Ensure PackageArchive contains the right build of Razor.Design package
* Re-order values in build\dependencies.props to ensure Razor.Design's package version is
overwritten.
* Convert additional package refs to project refs
Fixes https://github.com/aspnet/AspNetCore-Internal/issues/1708
* Update CodeCheck.ps1
Use coventional routes for link generation
This change enables using conventional routes for link generation when
using MVC conventional routes. This change makes MVC link generation
behaviour highly compatible with 2.1.
The way that this works is that we create endpoints for **MATCHING**
using the denormalized conventional route, but we tell those endpoints
to suppress link generation.
For link generation we generate a non-matching endpoints per-route with
the same order value.
I added the concept of *required value any* to link generation. This is
needed because for an endpoint to participate in link generation using
RouteValuesAddress it needs to have some required values. These details
are a little fiddly, but I think it's worth doing this feature
completely.
* Move contents of Microsoft.AspNetCore.Components.Services namespace to Microsoft.AspNetCore.Components
* Rename Components to Blazor
* Make Blazor server-side part of the shared framework.
* Add a System.Text.Json based TempDataSerializer
* Update DefaultTempDataSerializer
* Add common tests for DefaultTempDataSerializer & BsonTempDataSerializer
* Remove uses of NewtonsoftJson in tests solely required for temp-data support
Fixes https://github.com/aspnet/AspNetCore/issues/7255
* [MVC][Components] Prerendering + Robust reconnect
* Relayers prerendering support on a separate package on top of MVC and
components.
* Implements robust reconects with acknowledgements from the client.
* Improves interactive prerendering with the ability to reconnect to
prerendered components.
* Removes the need to register components statically when prerendering
them.
* Removes the need of using an element selector when prerendering an
interactive component.
* Updates the templates to use the new fallback routing pattern and
reenables the components test.
* Adds eslint to the Typescript project to help maintain a consistent
style.
* Adds logging to support better debugging based on the pattern used by
signalr.
* Fixes exception handling on the server to always report exceptions correctly to the client.
These are *new style* for configuring MVC in services. We're adding these to make
things feel a bit more tailored to those particular scenarios.
----
The main reason for this is that we've had repeated community asks for an
*API-optimized* way of configuring MVC. I don't think that using AddMvcCore
is a suitable building block, because it has too many options that you want.
I've think I've identified the reasonable set of features that should be part
of the default experience for APIs. All of these things are already pay-for-play
and are activated by the presence of attributes. The only additional cost is
loading of assemblies and a few additional inspections of the attributes
(cached).
----
Additionally the AddControllers experience is composible. You can add views
to it, or add pages and get the whole thing.
AddRazorPages is basically an alias for what AddMvc does today. We don't
currently have a way to add pages without controllers (the opposite is true).
Based on feedback we could specialize this more.
----
Branding and perception are important, and we've users ask for more flexibility
in what gets added. The plan is to update the templates to use this experience
in preview4, and see what kind of feedback we get.
* Make endpoint middleware explicit
This change makes the endpoint middleware explicit again, and updates
all of the templates.
The other change here is make UseEndpoints be the place where you
register endpoints. This is vital because it puts your code visually at
the point of the pipeline where it executes.
Lastly, I removed support for UseMvc with endpoint routing. This is
causing issues for some security features, and we're moving in the
direction of trying to make the middleware heavy implementation required
in 3.0. There are some issues we won't be able to fix in MVC if we can't
unambiguously know if UseMvc was used or the middleware.
Fixes: #8609
Currently exceptions thrown during prerendering are simply logged. This
change uses the existing *unhandled exception* mechanism of the
renderer/circuit to throw these. The result is that the developer
exception page just works for prerendering.
- no-ops except for
- Update PatchConfig.props (2835f85b6c)
- Add some additional logging to ErrorPageMiddlewareWebSite (#8049) (aka 1ca6202e7e)
- Put MVC's functional tests in a separate test group (#8118) (aka db3795b368)
- ignore the build queue (4f2a0edc97) change because we're not hitting Linux resource issues in `master` branch
- ignore baseline test changes (5661c41909 and d2a4435ac8) because they're not applicable in `master`
Possible fix to https://github.com/aspnet/AspNetCore/issues/7313
One of the characteristics of these failures were that the
test took long to run. The build log has warnings for
several long running tests. This might be a result of CPU
contention since mondo-ification that make MVC's functional tests
run with nearly every other test project in the solution
* Add some additional logging to ErrorPageMiddlewareWebSite
DeveloperExceptionMiddleware will log an error if rendering the exception page
throws. The test failure in https://github.com/aspnet/AspNetCore-Internal/issues/1730
suggests that we encountered an error like so but do not have anything further to go by.
This change adds logging to the test so we could identify possible issues
* Removes a bunch of trivial usage of Blazor
... in names and comments where we don't specifically mean Blazor.
* Remove obsolete Startup from Components app
* Move UseBlazor into Blazor.Server
Moves UseBlazor and the related features in Blazor.Server - along with
some other general cleanup of misc shared files.
Now Components.Server has a much slimmer set of dependencies (MVC is
gone) and doesn't contain the "double startup" pattern that we
introduced (sorry).
We'll revisit UseBlazor and the dependencies there once the new
MapFallbackToFile support is available from static files.
* minor PR feedback
* Update reference assemblies
* fix broken test
This change introduces some new heuristics to make it easier to use
'page' or other resevered parameter names as parameters in URL
generation.
--
The main change here is to allow the link generation tree to *ignore* a
value passed in to URL generation when it conflicts with an endpoint's
required values.
The main concern of this feature area is "how do we tell whether you are
linking to an action or a page?". Routing attempts to do the right thing
will requiring very little from the user in terms of expressing intent.
In this case, we try to tell the difference between an attempt to generate
a link to an action due to the presence of the 'action' parameter and
absence of the 'page' parameter. This obviously doesn't work when you
want to use 'page' as a non-reserved parameter in an action. The same
case occurs for pages, but users are already used to the idea that
'action' is a reserved word in MVC.
We can loosen this restriction when the value that's supplied for 'page'
is known not to be any existing value of the 'page' route value.
This approach seems somewhat reasonable but has many of the problems inherent
to this area. When it fails (the value you want to use for 'page' causes
a conflict) - it's going to be esoteric and hard to understand.
[Components] Prerrendering startup experience
* Introduces an IComponentPrerrenderer to handle Prerrendering
* MVC registers a basic static prerrrenderer.
* Components registers a more feature complete prerrender that will
handle reconnection to the original circuit after prerrendering in
the future to allow for prerrendered interactive components.
* Removes UseRazorComponents
* Removes the SPA fallback in favor of a catch all route in
Index.cshtml
* Moves the framework files to be served by the default StaticFiles
middleware in the pipeline by way of plugging specific providers
through options.
* Lifts UseSignalR(r => r.MapHub<ComponentHub>()) into startup and
replaces it with a shorthand for MapHub using endpoint routing.
* Adds extension methods to map components to selectors for a given
hub.
* Updates the razor component templates to include prerendering and use a razor page as the entry
point.
Changes:
* Make Visual Studio 2019 a prerequisite for building this repo
* Update .sln files
* Update Windows SDK to 17134
* Update developer docs
* Disable ANCM tests
* Update to .NET Core SDK 3.0 Preview 2
* Use Microsoft.NET.Sdk.Razor as a package consistently accross the repo
* React to changes in metadata from Microsoft.NETCore.App
* React to changes in .NET Core SDK
* Attempt to workaround CodeCheck.ps1 failure which doesn't repro locally or on different agents. Possibly due to differences in the version of the PowerShell task?
* Remove dead YML file
* Rename usages of win7-{x64,x86} to win-{x64,x86}
* Update KoreBuild to 3.0.0-build-20190219.1
Update FileResult tests to detect a bug for the status 416 RangeNotSatisfiable :
https://github.com/aspnet/AspNetCore/issues/4943
When the body is empty, the Content-Length header should be 0 to match the body length.
- add regression test for #4939
- add `[BindProperty]` doc comments
- add `<remarks>` to `BinderType` properties that recommend setting `BindingSource` in some cases
smaller issues:
- catch invalid `BinderType` values up front
- complete `BindingSource.ModelBinding` implementation: `IValueProvider` filtering was faulty
nits:
- accept VS suggestions e.g. remove unused variables
- "model binder" -> `<see cref="IModelBinder" /> implementation` in some doc comments
- #7052
- add MvcOptions.MaxModelBindingCollectionSize` and `MvcOptions.MaxModelBindingRecursionDepth`
nits:
- update syntax of a few `Resources.Designer.cs` files (I ran `/t:resx` on Mvc.sln)
- take VS suggestions in a few test classes
* Relayer MvcEndpointDataSource
Separates the statefulness of the data source from the business logic of
how endpoints are created.
I'm separating these concerns because one of the next steps will split
the MvcEndpointDataSource into two data sources.
* Simplify MvcEndpointInfo
Removing things that are unused and leftovers from the 2.2 design of
this feature.
* Remove per-route conventions
Removes the ability to target endpoint conventions
per-conventional-route. This was a neat idea but we have no plans to
ship it for now.
Simplified MvcEndpointInfo and renamed it to reflect its new purpose.
* Remove filtering from MvcEndpointDataSource
This was neat-o but we're not going to ship it like this. We're going to
implement filtering in another place. Putting this in the data source is
pretty clumsy and doesn't work with features like application parts that
need to be baked in addservices
* Simplify ActionEndpointFactory
* Split up data sources
* Use UseRouting in functional tests
I've rejiggered our functional tests to de-emphasize UseMvc(...) and
only use it when we're specifically testing the old scenarios.
UseMvc(...) won't appear in templates in 3.0 so it's legacy.
* Update templates
* Add minor PR feedback
* one more
This change enhances our ambient value logic to also deal with required
values. In 2.2 we introduced a 'required values' semantic to allow route
values to appear "to the left" of a route pattern for the purpose of
ambient values copying. This is a complicated way of saying "when you
like to a different endpoint then discard the ambient values".
What we didn't consider is that some ambient values are special (like
area). So basically, we'll allow an ambient value to be used if it's
part of the required values - even if we've already decided to discard
the ambient values.
This is a pretty surgical fix and only affected the desired scenario
based on tests.
-----
I also removed an optimization that I think is broken. I put an earlier
optimization in place that attempted to count ambient values as they
were "seen" to try and avoid some extra copying. This copying loop has a
cost even if it no-ops which is what I was trying to prevent.
Unfortunately since we added 'required values' - it's now possible for
an ambient value to be double-counted, which makes this optimization
incorrect.
- Removed ViewsFeatureProvider
- Removed PageArgumentBinder and its internal implementation DefaultPageArgumentBinder.
- Removed corresponding test classes/methods for all the above.
- Reacted to class/member changes in dependencies.
#7326
Changes:
* Remove obsolete targets which are unnecessary now that this repo no longer builds git submodules in a separate build process
* Remove the need for static analysis of 'ArtifactInfo' items
* Simplify how the code signing task is configured
* Remove unused repo tasks
* Remove duplicate lists of external dependencies and packages to be produced
* Remove obsolete build definition
* Remove obsolete build script parameters
* Add VisualStudioSetupOutputPath
Obsoletes RazorViewAttribute and RazorPageAttribute and removes all of
our usage of them. I've already made the changes to have the SDK stop
generating these.
.NET Core 2.0 reached EOL last year. This removes multi-targeting our test projects and test assets to only use .NET Core 2.1 and .NET Framework 4.6.1.
Changes:
* Fix broken tests and VS solutions caused by source code reorganization
* Add a check to validate generated code and solutions on PRs
* backport some source code reorg to src/Identity
* Fix startvs.cmd if you've already run build.ps1
* Add PR checks for tests on Linux/macOS
* Skip broken Nginx tests
* Add conditions to skip IIS tests on non-Windows platforms
- #4917
nits:
- test `ExceptionPolicy` logic in an input formatter
- remove old Mono workarounds in `SerializaterErrorTests`
- fix typo in `SerializableErrorTests` (not using theory data)
- For the flakey test replaced the default logger with Xunit's `ITestOutputHelper` in order to see what's going wrong when the flakey test will eventually fail.
aspnet/AspNetCore-Internal#1337
- #4866 3 of 3
- other than ignored parameters and properties, no vestige remains of alternate behaviours
- also remove `AllowAreas` use outside src/Mvc
- left the `IEnumerable<ICompatibilitySwitch>` implementations to avoid `breakingchanges.netcore.json` churn
- made the implementations more consistent
- left one `ConfigureCompatibilityOptions<MvcOptions>` subclass: `MvcOptionsConfigureCompatibilityOptions`
- note `AllowShortCircuitingValidationWhenNoValidatorsArePresent` default now applies to `TryValidateModel(...)` etc.
nits:
- updated `CompatibilityVersion` doc comments
- "currently unused" -> "currently ignored" in doc comments from part 2
- took a few VS suggestions
- VS seems to have cleaned up some trailing whitespace in files I had opened but didn't manually change
- #7156 2 of 3
- will leave the `IEnumerable<ICompatibilitySwitch>` implementations to avoid `breakingchanges.netcore.json` churn
- will leave one `ConfigureCompatibilityOptions<MvcOptions>` subclass: `MvcOptionsConfigureCompatibilityOptions`
- a few options remain as regular properties:
- `ApiBehaviorOptions.SuppressMapClientErrors` (default `false`)
- `MvcOptions.EnableEndpointRouting` (default `true`)
- `MvcOptions.MaxValidationDepth` (default `32`)
- `MvcJsonOptions.AllowInputFormatterExceptionMessages` (default `true`)
nits:
- move `IsEffectivePolicy(...)` check earlier in `AuthorizeFilter`
- correct a typo or two
This is a workaround for a workaround that currently have in d16p1.
The Razor SDK maps all netcoreapp3.0 projects to MVC-2.1 at design time,
however this only really works if you have the Razor.Design package.
Since we have internal builds available that support MVC-3.0 we can just
manually hardcode the correct targeting of the project.
- #7156 part 1 of ?
- add `CompatibilityVersion.Version_3_0` and make it the default
- remove tests of old versions
- also remove `CompatibilityVersion.Version_2_x` uses outside src/Mvc
- for functional tests of legacy routing, use `MvcOptions.EnableEndpointRouting` to control behaviour
- rename `StartupWith2xCompat...` classes to `StartupWithoutEndpointRouting`
- clean up comments mentioning `[Obsolete]` `CompatibilityVersion` values
- many of the affected options will be removed in subsequent PRs but this cleanup helps when searching entire repo
- correct `<value>` comments in `ApiBehaviorOptions`
nits:
- take VS suggestions in changed files
- remove src/SiteExtensions/global.json and let file in repo root "win"
- fix a few grammar errors VS or the spell checker noticed
- move `<value>` elements before `<remarks>` for consistency
- was undoing unintentional changes and noticed the inconsistency in a couple of additional files
* Regenerate Mvc functional test baselines
- whitespace likely changed due to a recent Razor change (but there've been so many!)
* Don't trim response content in `RazorPagesTest.Page_SimpleForms_RenderAntiforgery()`
- was inconsistent with generated baseline and `Trim()` in similar tests is generally not needed or correct
* Skip test method causing remaining two src/Mvc failures
- #4417 opened to restore these tests