* Fix RendererSyncContext.Post()
Fixes: #9683 - SignalR connection breaks on large DOM
The root cause here is a misbehaving sync context. It's not legal for a
Post() implementation to run a callback synchronously. We want that
behavior for most of the functionality Blazor calls directly, but Post()
should always go async or else various threading primitives are broken.
* Fix incorrect tests
These tests have the assumption that setting the result of a TCS will
execution continuations synchronously. This was a bug in our
SyncContext, and these tests needed updating to be more resiliant.
* Remove a delegate allocation
* Fix more null refs in Api Analyzers
* Make attributes used by analyzer public
* Compile analyzer tests against ref assemblies
* Turn on Nullable reference types and harden some null-checks
Fixes https://github.com/aspnet/AspNetCore/issues/8686
* CR feedback left over from #10227
* Begin adding E2E test case
* Add cookie auth and test login page
* Make E2E auth component work client-side too
* Restructure auth E2E tests around a router so there can easily be multiple such test components
* Add E2E test case for AuthorizeView
* Prepare for E2E test implementations
* Fix ToBaseRelativePath handling of hashes
... otherwise E2E test will fail, because we're using the hash to control server-or-client execution
* Decouple E2E execution mode from hosting mode
* Actual E2E tests for cascading authentication state
* Actual E2E tests for AuthorizeView (in "no authentication rule" mode)
* Fix inconsistent namespace
* CR: Manual ref assembly definitions for AuthorizeView/CascadingAuthenticationState
* Update versioning for local and PR builds to match Arcade versioning
* Mark CanCancelIAsyncEnumerableClientToServerUpload as flaky - cref aspnet/AspNetCore-Internal#2465
* Disable rollforward in project template tests (3.0.0-dev is older than 3.0.0-preview*). This prevents tests from rolling forward onto technically older bits
The Arcade SDK requires that the obj/ and bin/ folders be placed in the top-level artifacts/ folder of the repo. Although this PR does not complete our Arcade convergence, this is a step towards updating our repo to build with the Arcade SDK.
Changes:
* Set output path for build to artifacts/bin/$(ProjectName)/
* Set intermediate output path for build to artifacts/obj/$(ProjectName)/
* Cleanup .gitignore files (remove duplication between repo-root and tested gitignore files)
* Add code check which looks for project files that share the same name (could cause issues)
* Rename project files to have unique names (avoid race condition of build output)
* Update all locations which were hard-coded to expect bin/ and obj/ in the project directory
* Add overrides for tests which still assert test binaries exist in a given location relative to the source code
- 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.
* Make RouteAttribute non-inherited
Fixes: #5529
Inheriting and looking for inherited route attributes will cause nothing
but trouble. We had a bug tracking what to do about this and we decided
to make it really clear that routes are not inherited.
Previously the attribute was marked as inherited, but we woulnd't look
for inherited routes.
* add test
* Add Windows 7 and 8.1 testing on Helix
* Install SQL Server on-demand in Helix test queues
* Only install mssql on Windows runs
* Use exit /b
* Add targets to better support running helix locally
* Set maxretrycount to 2
* Handle IIS issues on win7/win8
* Make HelixPreCommand's fail the workitem
* Add a pre-generated test cert of IIS Express
* Update helix doc and ignore netsh script failures
* Fix bug in detecting Windows queues and disable Win 7 until we have queues ready
* Fix HttpSys functional tests on Helix
fixes#7975
There is a 'PreserveExecutionContext' property to turn the old behavior back on. Also I had to modify where IHttpApplication.CreateContext is called since that's what sets the IHttpContextAccessor, which depends on AsyncLocals!
This change adds detection of various SignalR configure-related calls to
the startup analysis infrastructure.
Also adds a shim that VS is going to call into to analyze the project
pre-publish.
* Move service registration before hosting startups run
- This allows IHostingStartup to see default service registrations and override them.
- Added a test to verify that hosting startup can see the IWebHostingEnvironment. Unfortunately this is used by MVC to get the application name before the container is baked. This was found when porting our workshop from 2.2 to 3.0
* Add yarn.lock file for NodeServices
* Remove references to 'npm install' (causes double-download of node modules) and replace npm commands in package.json with yarn for consistency
* Upgrade yarn to 1.15.2
- see #9923 for related discussion
- pin aspnet/EntityFrameworkCore dependencies
- chain aspnet/Extensions dependencies through aspnet/AspNetCore-Tooling instead
- run `darc` to grab the latest
- remove System.Text.Encodings.Web references
- now included in runtime.*.Microsoft.NETCORE.App packages
nits:
- copy a few `ReferenceResolution.md changes from aspnet/Extensions version
This is the first step, and just estabilishes a skeleton. The end goal
is organize our analyzers under this node because:
1. We're writing some 'top level' analyzers that depend on everything
else
2. We want to be able to service analyzers on the SDK schedule
(independent of runtime).
Next, we'll merge the MVC analyzers into this assembly since there's no
reason for them to be separate. The MVC API analyzers will remain a
separate package, but under this node. The component analyzers will
remain separate as they need to ship as a package, but will move under
this node as well.
Creating a sample for the header propagation package and some various
misc UX improvements based on building the sample.
A small list:
- allow duplicate inbound names
- de-dupe based on outbound names
- add sugar for configuration
- simplify pattern for transforming values
- add error message for missing middleware
Also a few small perf things.
I started this out by wanting to remove the following from the
configuration pattern:
```C#
options.Headers.Add("X-TraceId", null);
```
This pattern with null is undiscoverable, but we didn't provide
something simpler. The most common case was to add a custom collection
type so we can define sugar methods.
The next realization is that in practical case (dist tracing sample) you
either way to *key* off of the same inbound header twice, or you don't
have an inbound header at all, and you will synthesize the value every
time. This means that the way we're treating inbound header names is a
bit wrong. We don't want inbound header names to be unique, we want
*outbound header names to be unique*.
Next, I want to consolidate DefaultValue and ValueFactory. The problems
I saw with this:
- DefaultValue is a trap. It's rare to use a static value.
- ValueFactory really wants the header name *and* value
I think what's there now is much more terse to work with.
* Store component/element keys on RenderTreeFrame
Also refactored how RenderTreeFrame gets constructed. The previous arrangement of having ad-hoc ctor overloads for different scenarios became intractible (too many combinations to avoid clashes; risk of accidentally losing field values when cloning). There's now one constructor per RenderTreeFrameType, so you always know where to add any new field values, and implicitly guarantees you don't lose other field values because adding a new param forces updates at all the call sites.
* Add StackObjectPool, which will be useful momentarily
* Support keyed insertions/deletions
* Refactor AppendDiffEntriesForRange to prepare for adding "move" logic
* Apply permutations on the JS side
* Handle keyed moves by writing a post-edit permutation list
* Shrink KeyedItemInfo struct
* Include sourcemaps when building client-side Blazor apps with ReferenceFromSource
* Update struct length of edit frames now it's explicit layout
It's longer now because all the reference-type fields, except the last, now have to be 8 bytes for compatibility with 64-bit runtimes. Previously on Mono WebAssembly the reference-type fields were all 4 bytes.
* Tolerate clashing keys (i.e., produce a valid diff, even if suboptimal)
* Tolerate keys being added/removed incorrectly
* E2E test harness for 'key'
* Some more unit test cases
* Invert diffing logic to prefer matching by key over sequence
Previously it preferred sequence over key, but that's wrong, and surfaces as bugs when you mix keyed and unkeyed items. We need to prefer key over sequence, because key is meant to guarantee preservation, whereas sequence is just best-effort preservation.
* Make unit test cases more adversarial
* First actual E2E test
* In E2E test, verify correct preservation of components
* E2E tests for simple insert/delete cases (with and without keys)
* E2E test for reordering. Also extend other tests to verify simultaneous editing.
* E2E test for many simultaneous changes
* Update reference sources
* CR: Avoid x = y = z
* CR: Only use 'finally' for actual cleanup
* CR: Clean up RenderTreeFrame assignment
* CR: Include 'key' in RenderTreeFrame.ToString()
* CR: Avoid "new T()" in StackObjectPool
* CR: Make KeyedItemInfo readonly
* CR: Handle change of frame type with matching keys (and sequence)
* CR: Add E2E test showing form + key scenarios
* Preserve focus across edits
* Tweak E2E test case
* In client-side Blazor, prevent recursive event handler invocations
* Actual E2E tests for moving form elements
This changes the recipe for client-side blazor to use similar primitives
to server side applications.
---
I ignored auto-rebuild support because it's currently dead code until we
have that in VS. If we add auto-rebuild to ASP.NET Core - we'd probably want
to make that a separate gesture inside `IsDevelopement()` like other
dev-time features anyway.
---
The static files hookup is a special thing because creating the file
server for a client-side Blazor app involves some non-trivial work. We
plan to make this better in the future.
What's nice about this pattern is that the implementation is pretty
simple and literal, and it scales fine if you have multiple Blazor
client-side apps.
I didn't provide a lot of options here, it's pretty much the same as
UseBlazor.
---
I feel pretty good about the wireup with routing to use the
`index.html` from the client app. I think it's pretty to-the-point.
* EnableAzurePipelinesReporter for helix
* Update Helix SDK
* Revert a fix that broke things even more
* Try publishing test assets
* Try fixing Kestrel tests on Helix
* Try a temp file in the working directory
* Skip Http2Spec tests on Debian 8
* Missed update
* Try a different format
* Disable failing test on Fedora
* Mark flaky test