* [Blazor] Allows multiple components as entry points
* Removes all overloads that register a component statically with aborts
selector.
* Updates render component to have a RenderMode parameter that indicates
how the component must render. Valid values are Static, Server, and
ServerPrerendered.
* When using Server or ServerPrerendered we emit marker comments into
the page that are later used by blazor.server.js to bootrstrap a
blazor server-side application.
This change prevents thread pool starvation when running a bunch of
selenium-based tests, by turning the blocking wait for a WebDriver to
start into an async wait.
This also seems to help with speed, and reliability since we're not
running too many browsers at once. I was experencing timeouts, and
seeing them in the debugger while running tests locally, this no longer
happens.
* Revert "Revert "Improve components infrastructure (#12145)" (#12679)"
This reverts commit e2d57e2806. The improvement to components infrastructure is now reinstated with the following changes:
* Check in release JS artifacts and use them as a fallback when it's not possible to build npmproj.
* Dont' build nodejs in source build.
This change adds a fail-fast mechanism to our E2E tests based on
the browser console. This will fail super hard if an unhandled exception
is thrown.
I think it would be interesting to also see if we could do the same
thing for 404s.
The goal of this change is to make it so that the E2E tests can fail
faster (3-4s) than the 30s timeout in the case that something
catastrophic happens. As a nice side benefit you get to see the
exception message.
* Immediately releases the circuit when the client disconnects gracefully.
* This functionality is limited to websockets.
* We are able to release the circuit in the following situations:
* The user closes the browser.
* The user navigates away.
* The user reloads the page.
* Remove generated Web.JS javascript files files
* Build NodeJS project referenced by managed projects by default
* Build Web.JS before other CI jobs
- We can't build Web.JS on Linux Musl for example
* Make BuildAll not override explicit BuildJava/NodeJS/Native/Managed settings
* Capture CodeCheck logs for debugging
* Skip NodeJS projects when generation ref assemblies
* Do not build dependent projects if NodeJS is not built
* Make build fail immediately if BuildNodeJS is true but NodeJS is not installed
* Do not build nodejs in installer builds
* fix#12516 by cleaning up error page
* add a Diagnostics.slnf because I was there
* missed the IIS update
* update WebHost's error page
* Fix slnf path
* Fixes multiple issues that happened due to the E2E tests not running on the CI
* Enforces prerequisites for E2E tests on the CI and when building projects with E2E tests.
* Re-enables the E2E tests for templates.
* Replace usages of $(CI) with $(ContinuousIntegrationBuild)
* Move RepoTasks to eng/tools/
* Remove dead code
* Update build.sh/ps1 to invoke Arcade instead of KoreBuild
* build/repo.props => eng/Build.props
* build/CodeSign.{props,targets} => eng/Signing.props
* build/repo.targets => eng/Build.props, eng/CodeGen.proj, and eng/AfterSolutionBuild.targets
* Remove AddAllProjectRefsToSolution.ps1
* Put selenium process tracking into artifacts/tmp/
* build/docker => eng/docker
* Move content from korebuild.json to global.json
* Remove cibuild.{sh,cmd} and update ci.yml
* Ensure vswhere detects BuildTools installations
* Remove sign check exclusions (Arcade does not support)
* list VS required components in global.json
* Update CodeCheck.ps1
* Update arcade (#11143)
* Fixups to broken build
* capture test results in xunit form
* attempt to fix code check
* restore before linux build
* remove duplicate signinfos
* More build fixes
* exclude node_modules from unique project check
* fixup signing props
* More build fixes
* Remove unused NoWarns
* Skip building site extension
* Suppress xunit color in console output
* Install x86 runtime
* Run KillProcesses.ps1 at end of build on CI
* activate env vars in codecheck.ps1
* Fix signing and generate build manifests
* Fixup code check and linux installers build
* Remove custom restore targets
* Import flaky test props
* Restore original manifest generation code and set warnAsErrors=false
* Alwasy restore the toolset
* More attempts at build fixes
* run restore before building deb/rpm packages
* pre-install Yarn.MSBuild
* Remove WIX workaround
* Attempt to fix RPM installers and x86 build
* Fix helix tests, java auto-detection, and code gen steps
* Globally disable MSBuild node resuse and capture MSbuild crash logs
* Cleanup build invocation for installers
* Set max time on xunit tests to 15 min
* Update helix-test.yml
* Fix Hosting tests
* Fix TestHost
* Fix Negotiate.Test
* Fix Mvc tests
* Capture results
* Fix Hosting tests
* Fix Kestrel tests
* Fix ServerComparison tests
* Fix DefaultBuilder functional tests
* Skip template tests
Need to run pack before running tests on mac/linux now
* Fix Identity test
* Fix ServerComparison tests
* Verify nginx installation on ubuntu
* Verify nginx installation?
* Try adding to path
* Try symlink
* Sudo?
* Woot it works
* Disable timeout
Template tests require more than 15 mins
* list env vars
* Use correct dotnet_home
* Prepent path instead
* Fix npmproj tests
* Fix CORS tests
* Debug signalr tests
* Debug signalr
* Capture bin
* Try building templates sequentially
* Debug signalr
* Cleanup
* Disable signalr npm tests
* Debug template test
* Try to fix templates again and make steps more reliable
* Cleanup
* Feedback
- Make sure we always await the last flush task before calling FlushAsync
again instead of preemptively calling FlushAsync and checking to see
if the ValueTask is incomplete before bothering to acquire the _flushLock
- This now acquires the _flushLock fore every call to Response.Body.Write
whereas this only happened for truly async writes before.
- I don't think this is a big concern since this should normally be uncontested,
and DefaultPipeWriter.FlushAsync/GetResult already acquire a lock.
This takes PathNormalizer from Kestrel to normalize the request path and prevent traversals. (e.g. "/./" and "/../").
In 2.1 only HttpSys was affected (https://dev.azure.com/dnceng/internal/_git/aspnet-AspNetCore/pullrequest/1480). In 2.2 HttpSys and IIS-in-proc share this code (with additional tests). In 3.0 we'll refactor it to use more shared source across all three servers.
This takes PathNormalizer from Kestrel to normalize the request path and prevent traversals. (e.g. "/./" and "/../").
In 2.1 only HttpSys was affected. In 2.2 HttpSys and IIS-in-proc will share this code (with additional tests). In 3.0 we'll refactor it to use more shared source across all three servers.
`GetRuntimeInterfaceMap` is a rather expensive API and it doesn't look like the use here is warranted.
The replacement should have equivalent behavior.
This is a massive set of changes to Kestrel to remove the existing pubternal transport layer and implement a public facing API for listeners and clients, see the details here #10308.
This change only has the server side pieces of the story as I don't want to add the client APIs without having ported SignalR to use them. Here are the highlights:
- Transport.Abstractions is empty (will be removed in a separate PR as it requires removing it from a ton of places)
- TransportConnection has been moved to Connection.Abstractions (we can decide if we need to consolidate with DefaultConnectionContext in a later PR)
- Added FileHandleEndPoint which allows binding to a file handle (could be a pipe or tcp handle)
ListenOptions has been gutted for most pubternal API and returns various types of binding information . The source of truth is the EndPoint instance.
- Cleaned up a bunch of libuv tests decoupling them from Kestrel.Core
## Breaking changes
- Removing pubternal API is itself a breaking change but one that we already planned to do.
- We've removed the ability to set the scheduling mode on Kestrel
- DisposeAsync was added to ConnectionContext
- NoDelay was removed from ListenOptions. This has been moved to each of the transports. One major difference though is that it's no longer localized per endpoint but is global. We'd need a derived EndPoint type (or maybe extend IPEndPoint) to store both the socket options and the binding information.
Attempt to improve reliability of running yarn commands. Our project structure might cause yarn to be launched multiple times. According to yarn docs, this option should avoid conflicts between multiple instances of yarn
https://yarnpkg.com/en/docs/cli/#toc-concurrency-and-mutex
Ryan Brandenburg
Javier Calvarro Nelson
Ryan Nowak
John Luo
Brennan
Chris Ross
Andrew Stanton-Nurse
Carlos J. Aliaga
Doug Bunting
Nate McMaster
Dylan Dmitri Gray
Hao Kung
Stephen Halter
Günther Foidl
Chris Ross (ASP.NET)
YPTopMan
Justin Kotalik
Michal Strehovský
David Fowler
Ben Adams
Pavel Krymets