* Put Razor.Design.Test and Razor.Language.Test in a different test group (#6725)
* Move dotnet watch to a seperate test group (#6730)
* Reuse root `version.props` in Templating
- do not let Templating get behind branding changes
* Revert "Put Razor.Design.Test and Razor.Language.Test in a different test group (#6725)" (#6753)
This reverts commit 563ff7c639.
* Revert file watch test changes
* Add Components packages to shared fx
* Add Microsoft.AspNetCore.Components \ Microsoft.AspNetCore.Components.Browser to shared fx
* Update build to use Microsoft.InteropJS package produced from Extensions repo
* Remove some package references from components template
Fixes https://github.com/aspnet/AspNetCore/issues/6442
* Fix#6102 - Intense CPU utilization on page change
The issue here was that every time a Razor Page changed, we would
subscribe an additional time to the endpoint change notifications. This
means that if you tweaked a page 30 times, we would update the address
table 31 times when you save the file. If you were doing a lot of editing
then this would grow to a really large amount of computation.
The fix is to use DataSourceDependentCache, which is an existing utility
type we developed for this purpose. I'm not sure why it wasn't being
used for this already. We're already using DataSourceDependentCache in a
bunch of other places, and it's well tested.
I also tweaked the stucture of this code to be more similar to
EndpointNameAddressScheme. This involved some test changes that all
seemed like good cleanup. The way this was being tested was a little
wonky.
(cherry picked from commit a5658a8c95)
- Change the upgrade message body to use the transport pipe instead of the request body pipe.
- Remove some logic from the base type (more can be removed but this is a conservative change)
- Improve performance of the ReadAsync call
* Fixed the bug in the windows service host where if application stop is requested, the service wouldn't know about it.
* Fixed a typo.
* Update src/Hosting/WindowsServices/test/Microsoft.AspNetCore.Hosting.WindowsServices.Tests.csproj
* Removed unneeded EditorBrowsable for internal API.
* Fixed tests to ignore Linux and MacOS.
* Added new line to end of file.
* Using [ConditionalFact] instead of [Fact].
* Only use async marshalling to renderer sync context when necessary
Note that the lifecycle methods already take care of capturing the correct sync context, so continuations will already be serialized.
Avoiding an extra layer of asynchrony keeps the semantics of rendering closer to the WebAssembly cases, and will fix a range of intermittent errors in the wild.
* Add E2E test of triggering rendering from outside the sync context
* Actually throw if attempting to render from incorrect sync context
* Add "Dispatch" API
* Handle dispatch within dispatch. Also test Dispatch on WebAssembly.
* Avoid heap allocation
* Simplify E2E test
* Replace Dispatch() with Invoke() and InvokeAsync()
* Add E2E test to validate async execution order
* Clean up
* Fix#6102 - Intense CPU utilization on page change
The issue here was that every time a Razor Page changed, we would
subscribe an additional time to the endpoint change notifications. This
means that if you tweaked a page 30 times, we would update the address
table 31 times when you save the file. If you were doing a lot of editing
then this would grow to a really large amount of computation.
The fix is to use DataSourceDependentCache, which is an existing utility
type we developed for this purpose. I'm not sure why it wasn't being
used for this already. We're already using DataSourceDependentCache in a
bunch of other places, and it's well tested.
I also tweaked the stucture of this code to be more similar to
EndpointNameAddressScheme. This involved some test changes that all
seemed like good cleanup. The way this was being tested was a little
wonky.
- WebSocketProtocol.CreateFromStream makes the netstandard ManagedWebSocket which uses the inefficient versions of Stream overloads.
- Updated the samples to use the new Memory<byte> overloads
* Replace UseServerSideBlazor with UseRazorComponents, which doesn't require Blazor build artifacts
* Make UseRazorComponents serve blazor.server.js from embedded resource
... so we don't need a build step to put it on disk somewhere.
* Fix TestServer
* Update ComponentsApp not to use Blazor build targets
* Update ComponentsApp.App sample to use new build package
* Update string constant in test
* Rename blazor.*.js to components.*.js
* Ensure correct build order
* Update nav menu title in Components sample app
* Fix remaining paths
* Switch ComponentsApp.App to use Sdk="Microsoft.NET.Sdk.Razor"
* Update mono.cecil version
* CR: Replace FrameworkFilesProvider with EmbeddedFileProvider
* CR: Use ManifestEmbeddedFileProvider
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.
NTaylorMullen
Ajay Bhargav Baaskaran
Justin Kotalik
Ajay Bhargav Baaskaran
Pavel Krymets
Nate McMaster
John Luo
John Luo
Steve Sanderson
Doug Bunting
Chris Ross
Pranav K
James Newton-King
Ryan Nowak
BrennanConroy
Stephen Halter
Mikael Mengistu
David Fowler
Travis Illig
Kahbazi
Doug Bunting
Ivan Zlatanov
Chris Baudin
Ben Adams
Nate McMaster
Rick Anderson
Javier Calvarro Nelson