* 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.
- 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
This wasn't properly forwarding the base path to the configuration.
Basically nothing was setting RemainingArguments. We have a test project
that sets the base path, but it was never used when debugging locally.
I also cleaned this up a bit and changed it to use dotnet exec. This
allow you to debug the CLI and related server pipeline, but has the
tradeoff of not rebuilding.
Follow-up to #6078
This should solve race conditions in restoring .wixproj files.
Co-authored-by: Nate McMaster <natemcmaster@users.noreply.github.com>
Co-authored-by: Justin Kotalik <jkotalik@users.noreply.github.com>
- Remove per request allocations by implementing IThreadPoolWorkItem on the IISHttpContext.
- Removed per operation allocations by using UnsafeQueueUserWorkItem in AsyncIOOperation.
- This should also reduce overhead by removing non-essential ExecutionContext propagation logic
Changes:
* Build installer projects in parallel.
* Use `ProjectReference` to ferry bits between installer projects.
* Don't build wixproj to a unified output directory. This was only done to simplify finding file paths to MSI's built by other projects, but ProjectRef solves that.
* Add a VS solution for working on wixproj and the associated C++ custom actions.
* To make wixproj work in VS, I replaced default globs with listing .wxs and .wxl files in the wixproj file.
* Add a target to copy the installers to the artifacts directory according to the layout described in /docs/Artifacts.md
The following package archives which are no longer used by partner teams. It is expected that these will be replaced by targeting packs.
* LZMA (was used by dotnet-cli)
* Package zips (ended up not getting used by anyone)
* Compat package zips (was used by Azure Web Apps)
Update the build scripts to support building subfolders or subgroups of projects
* Add build scripts for ci
* Remove obsolete scripts
* Add flags like --test and --pack to control running just test or packaging
* Add flags like --managed and --native to control building sub-types of projects
* Remove KoreBuild bootstrapper flags
* Update to extensions 3.0.0-preview.18619.1 (needed to get a fix for aspnet/Extensions#815 to make this change work on MSBuild.exe)
These are being pulled out of the shared framework and will ship as NuGet packages. These assemblies have a dependency on the IdentityModel APIs which do no yet fit the guidelines the shared framework.
cref aspnet/AspNetCore#3755
This was never supposed be be merged into release/2.2 or master since both those branches include aspnet/KestrelHttpServer#2844.
This reverts commit 019ba081d3.
This simplifies the way that we publish files to our network drop share.
Changes:
* Instead of explicitly listing every file that needs to publish, use directories to classify packages and artifacts into different categories.
* Add documentation for the expected layout of artifacts/
* Remove the need for static analysis to determine which packages go to which project
* Add the MSBuild property "IsProductPackage" to .csproj files which ship as a package to NuGet.org.
As a result of removing Razor's VS projects and upgrading all projects to netcoreapp3.0, we no longer need dependency variable for .NET Core 1.x and 2.x and Visual Studio packages.
Changes:
* Remove 'StandardTestTfm'
* Remove variables for .NET Core 1.0, 1.1, 2.0, 2.1, and 2.2
* Remove VSIX variables
* Stop generating 'branding.props' - this hasn't been used in a while and is no longer needed
- #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
- #3754
- remove `#if`'s for multi-targeting where source is never multi-targeted
- left `StreamPipeReader`, `StreamPipeWriter` and their test classes alone because they're moving to CoreFx
- #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.
Replaces package references the following packages with local code:
Microsoft.AspNetCore.Certificates.Generation.Sources
Microsoft.Extensions.CopyOnWriteDictionary.Sources
Microsoft.Extensions.ClosedGenericMatcher.Sources
Microsoft.Extensions.ObjectMethodExecutor.Sources
Microsoft.Extensions.PropertyActivator.Sources
Microsoft.Extensions.PropertyHelper.Sources
Microsoft.Extensions.RazorViews.Sources
Microsoft.Extensions.SecurityHelper.Sources
Microsoft.Extensions.StackTrace.Sources
Microsoft.Extensions.WebEncoders.Sources
Changes:
* Ensure IIS managed and pkg projects build after the native projects
* Update projects to build test
* Update CI checks to build on macOS and Linux
* Use package baselines to manage ANCM packages
All other properties (`Predicate`, `ResponseWriter` and `AllowCachingResponses`) have a setter but `ResultStatusCodes` doesn't.
Without a setter, reusing the same status to http status code mapping is impossible and leads to duplicate code that looks like this:
```csharp
private static void ConfigureHealthChecks(IApplicationBuilder app, HealthCheckServiceOptions options)
{
app.UseHealthChecks("/health", new HealthCheckOptions
{
ResultStatusCodes =
{
[HealthStatus.Healthy] = StatusCodes.Status200OK,
[HealthStatus.Degraded] = StatusCodes.Status400BadRequest,
[HealthStatus.Unhealthy] = StatusCodes.Status503ServiceUnavailable
}
});
foreach (var name in options.Registrations.Select(e => e.Name))
{
app.UseHealthChecks($"/health/{name}", new HealthCheckOptions
{
Predicate = registration => registration.Name == name,
ResultStatusCodes =
{
[HealthStatus.Healthy] = StatusCodes.Status200OK,
[HealthStatus.Degraded] = StatusCodes.Status400BadRequest,
[HealthStatus.Unhealthy] = StatusCodes.Status503ServiceUnavailable
}
});
}
}
```
With a setter, this code could be rewritten in a *don't repeat yourself* (DRY) way:
```csharp
private static void ConfigureHealthChecks(IApplicationBuilder app, HealthCheckServiceOptions options)
{
var resultStatusCodes = new Dictionary<HealthStatus, int>
{
[HealthStatus.Healthy] = StatusCodes.Status200OK,
[HealthStatus.Degraded] = StatusCodes.Status400BadRequest,
[HealthStatus.Unhealthy] = StatusCodes.Status503ServiceUnavailable
};
app.UseHealthChecks("/health", new HealthCheckOptions
{
ResultStatusCodes = resultStatusCodes
});
foreach (var name in options.Registrations.Select(e => e.Name))
{
app.UseHealthChecks($"/health/{name}", new HealthCheckOptions
{
Predicate = registration => registration.Name == name,
ResultStatusCodes = resultStatusCodes
});
}
}
```
* Workaround problems when opening solution files in Visual Studio (#4569)
Changes:
* Condense Routing.sln into HttpAbstractions.sln
* Workaround NU1105 by adding all ProjectReferences to the .sln
* Workaround exceptions in the ReferencesHostBridge by moving Reference items to a temporary item group
* Add a 'startvs.cmd' script for launching VS with the right env variables
* Remove RangeHelper test project
* Move RangeHelper tests into StaticFiles.Tests and add target for NPM restore
* Convert Session to use Reference and move to Middleware folder (#4576)
* Add RoutingSample.Web to HttpAbstractions.sln
Changes:
* Condense Routing.sln into HttpAbstractions.sln
* Workaround NU1105 by adding all ProjectReferences to the .sln
* Workaround exceptions in the ReferencesHostBridge by moving Reference items to a temporary item group
* Add a 'startvs.cmd' script for launching VS with the right env variables
* Remove RangeHelper test project
* Move RangeHelper tests into StaticFiles.Tests and add target for NPM restore
Martin Perry
Justin Kotalik
Chris Ross
John Luo
Pranav K
Pavel Krymets
James Newton-King
Ryan Nowak
BrennanConroy
Ajay Bhargav Baaskaran
Stephen Halter
Mikael Mengistu
Steve Sanderson
David Fowler
John Luo
Doug Bunting
Travis Illig
Kahbazi
Nate McMaster
Doug Bunting
Ivan Zlatanov
Chris Baudin
Ben Adams
Nate McMaster
Rick Anderson
Javier Calvarro Nelson
Dávid Kaya
Hao Kung
Luke Latham
Bart Wolff
dotnet-bot
Martin Costello
N. Taylor Mullen
Mazioudi Anas
Hamza Assyad
Justin Kotalik
Kristian Hellang
Ajay Bhargav Baaskaran
alenros
noslaver
dotnet-maestro-bot
Artak Mkrtchyan
Nate McMaster
Cédric Luthi