* Workaround for DomException when invoking cache.put
Invoking cache.put could sometimes result in exceptions being thrown. While this seems to have been fixed in Chromium - https://bugs.chromium.org/p/chromium/issues/detail?id=968444,
we've had several reports of this in our repo. The fix here is to write defensively when working with the cache apis since they appear to behave in unexpected ways..
Fixes https://github.com/dotnet/aspnetcore/issues/20256
* Fixup
* Undo overzealous merge choices
* Undo temporary changes applied when part of the repo was building in the blazor-wasm branch
* Skip SPA template tests in 3.1
This pull request updates the following dependencies
[marker]: <> (Begin:e908e90a-0c22-4c54-b254-08d79557a113)
## From https://github.com/dotnet/efcore
- **Subscription**: e908e90a-0c22-4c54-b254-08d79557a113
- **Build**: 20200520.1
- **Date Produced**: 5/20/2020 5:36 PM
- **Commit**: 85b57af827aa71b77d673e813e046d081c8027ed
- **Branch**: refs/heads/internal/release/3.1
- **Updates**:
- **Microsoft.EntityFrameworkCore.Tools**: from 3.1.4 to 3.1.5
- **Microsoft.EntityFrameworkCore.InMemory**: from 3.1.4 to 3.1.5
- **Microsoft.EntityFrameworkCore**: from 3.1.4 to 3.1.5
- **Microsoft.EntityFrameworkCore.Relational**: from 3.1.4 to 3.1.5
- **Microsoft.EntityFrameworkCore.Sqlite**: from 3.1.4 to 3.1.5
- **dotnet-ef**: from 3.1.4 to 3.1.5
- **Microsoft.EntityFrameworkCore.SqlServer**: from 3.1.4 to 3.1.5
[marker]: <> (End:e908e90a-0c22-4c54-b254-08d79557a113)
* Improve build reliability
- ensure `ResolveCustomReferences` target executes before packages are used
- `ResolveAssemblyReferences` and `ResolveAssemblyReferencesDesignTime` targets run too late
- e.g. failed builds of Microsoft.AspNetCore.WebUtilities or Microsoft.AspNetCore.Hosting when building from root
- add `GetReferenceProjectTargetPathMetadata` for ease of use as well as reliability
- avoids extra work to get existing metadata (ref/ projects execute no tasks in this target)
nit: rename `@(ReferenceProjectMetadata)` -> `@(ReferenceProjectTargetPathMetadata)`
* Ensure `GetTargetPathMetadata` target runs with `$(TargetFramework)` set
- ref/ projects all multi-target and otherwise no-op this target
* Revert "Fix various "Type or namespace not found" errors (#20736)"
- change is no longer needed with other fixes in this PR
This reverts commit 8218d6e0e7.
* Fix use of precedence in endpoint routing DFA
Fixes: #18677Fixes: #16579
This is a change to how sorting is use when building endpoint routing's graph of
nodes that is eventually transformed into the route table. There were
bugs in how this was done that made it incompatible in some niche
scenarios both with previous implementations and how we describe the
features in the abstract.
There are a wide array of cases that might have been impacted by this
bug because routing is a pattern language. Generally the bugs will involve a
catch-all, and some something that changes ordering of templates.
Issue #18677 has the simplest repro for this, the following templates
would not behave as expected:
```
a/{*b}
{a}/{b}
```
One would expect any URL Path starting with `/a` to match the first
route, but that's not what happens.
---
The change supports an opt-in via the following AppContext switch:
```
Microsoft.AspNetCore.Routing.UseCorrectCatchAllBehavior
```
Set to true to enable the correct behavior.
---
The root cause of this bug was an issue in how the algorithm used to be
build the DFA was designed. Specifically that it uses a BFS to build the
graph, and it uses an up-front one-time sort of endpoints in order to
drive that BFS.
The building of the graph has the expectation that at each level, we
will process **all** literal segments (`/a`) and then **all** parameter
segments (`/{a}`) and then **all** catch-all segments (`/{*a}`). Routing
defines a concept called *precedence* that defines the *conceptual*
order in while segments types are ordered.
So there are two problems:
- We sort based on criteria other than precedence (#16579)
- We can't rely on a one-time sort, it needs to be done at each level
(#18677)
---
The fix is to repeat the sort operation at each level and use precedence
as the only key for sorting (as dictated by the graph building algo).
We do a sort of the matches of each node *after* building the
precedence-based part of the DFA, based on the full sorting criteria, to
maintain compatibility.
* Add test
* Add a scenario for measuring navigating between components
* Apply suggestions from code review
Co-authored-by: Steve Sanderson <SteveSandersonMS@users.noreply.github.com>
Co-authored-by: Steve Sanderson <SteveSandersonMS@users.noreply.github.com>
WASM runtime does not like it when you attempt to load satellite assemblies
for two sets of non-neutral cultures - the first is always loaded. This change
defers loading satellite assemblies until after Program.Main has executed
and the developer has configured the culture for the application.
Fixes https://github.com/dotnet/aspnetcore/issues/21433
* Re-use the Blazor app for stress runs
Our current stress runs re-used the perf tests which recreated the blazor app on each run. Perf runs are meant to run
and be done, however, we want stress apps to be long lasting to capture things like memory leaks.
This change creates a fork in the tests to support stress runs that re-use the app between runs.
* Silence the runtime output from the debugger
* Update src/Components/Web.JS/src/Platform/Mono/MonoPlatform.ts
Co-authored-by: Pranav K <prkrishn@hotmail.com>
Justin Kotalik
Sébastien Ros
Pranav K
Javier Calvarro Nelson
Brennan
Safia Abdalla
William Godbe
DotNet Bot
Doug Bunting
Ryan Nowak
Steve Sanderson
John Luo
Larry Ewing
dotnet-maestro[bot]