- 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.
- 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
- Today in Kestrel, we reuse the IFeatureCollection per connection and per Http2Stream. This PR aims to take advantage of that same technique and affinitize the HttpContext and friends so that they are only allocated per connection.
- ReusableHttpContext and friends mimic the functionality of DefaultHttpContext but is sealed and has no overridable methods.
- Introduce IHttpContextContainer which allows servers to cache the HttpContext and friends across requests.
.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.
* Auto-install local copy of selenium-standalone on build
* Automatically start/stop selenium-standalone when running E2E tests
* Update after rebase
* Exclude node_modules from E2ETests project
* Avoid deadlocks
* Include E2E tests when running all tests in src/Components
* Be more forgiving about waiting for selenium-server to be ready
* Update usage of shared source file
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
- Remove per request allocations on the thread pool by implementing IThreadPoolWorkItem on Http2Stream
- Made generic version of Http2Stream to store the IHttpApplication instead of using a tuple
- Removed passing of IHttpApplication<TContext> everywhere
- #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
Mikael Mengistu
John Luo
Doug Bunting
John Luo
BrennanConroy
Pranav K
Steve Sanderson
Travis Illig
Kahbazi
David Fowler
Stephen Halter
Chris Ross
Nate McMaster
Doug Bunting
Ivan Zlatanov
Pavel Krymets
Justin Kotalik
Chris Baudin
Ryan Nowak
Ben Adams
James Newton-King
Nate McMaster
Rick Anderson
Javier Calvarro Nelson
Ajay Bhargav Baaskaran
Dávid Kaya
Hao Kung
Luke Latham
Bart Wolff
dotnet-bot
Martin Costello
N. Taylor Mullen
Mazioudi Anas
Hamza Assyad