* 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.
- This completely removes the per request allocation until the feature is used.
- In order to make this change viable, we need to introduce a new HttpContextFactory that can accept new services without adding 2^n constructors. As a result, this change introduces a DefaultHttpContextFactory that takes an IServiceProvider and resolves dependencies based on the needs of the DefaultHttpContext and features.
- Throw in the older HttpContextFactory constructor when the IServiceScopeFactory is null
- It also saves us from revving the feature collection version unnecessarily.
* Move Components.Build to blazor/src/. No content changes yet.
* Rename Components.Build to Blazor.Build and update file paths
* Move Components.Build.Test files. No content changes yet.
* Update contents in Blazor.Test
* Fix names of props/targets files
* Add minimal Components.Build package that just imports Razor targets and analyzer
* Make Blazor.Build depend on Components.Build and get Razor compilation targets from there
* Fix version of reference from .Blazor.Build to .Components.Build
* Fix signing error on local builds
* Update artifacts.props
Part of #4246
Changes:
* Update source code layout to follow the new conventions for this repo
* Update project files to use `<Reference>`
* Update targets to build NPM packages
* Update BuildTools to support custom 'restore' and 'test' targets
Ryan Nowak
David Fowler
BrennanConroy
Ben Adams
James Newton-King
Chris Ross
Nate McMaster
Nate McMaster
Kahbazi
Justin Kotalik
Steve Sanderson
Rick Anderson
Javier Calvarro Nelson
Pavel Krymets
Pranav K
Dávid Kaya
Hao Kung