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
* Don't re-use DefaultHttpContext if IHttpContextAccessor is in use
- Consumers may still get null or an ODE but will never end up with data from a different request.
- Make sure an ODE is thrown from all properties on HttpContext after the request is over.
**Description**
An infinite loop can happen in routing if there is a catch all route with host name matching.
This problem is caused by the DFA matcher builder giving an incorrect exit destination to policies. Currently the exit destination is the catch all state, so the policy will transition to itself when there is no match. It will run again, transition to itself again, run again, etc. This causes the policy to run forever.
What should happen is the host name policy fails, it transitions to the final state with no candidates, and the route matcher does not match any endpoints. The browser is returned a 404 status.
**Customer Impact**
This problem shows up in this situation:
1. If a customer has configured a catch all route in their app
2. The catch all route has host matching
3. A browser makes a request to the server that matches the catch all route but doesn't match the host name
The route matcher will run forever, using up a threadpool thread. When threadpool threads are exhausted the server will stop responding.
**Regression?**
No.
**Risk**
Medium. The fix is simple but route matching is complex, and routing runs with every request.
* Always generate checksums as last part of publish job
* Initialize props correctly
* Fix wildcard
* Import Arcade SDK
* Add NoWarn MSB4011
* Make import conditional on GenerateChecksums
* Select specific files to checksum
* Respond to feedback
* AfterTargets -> BeforeTargets
* Update dependencies from Arcade
* Try publishing checksums
* Fix some errors
* Set RelativeBlobPath
* Fix publish location
* Centralize ChecksumExtension
* Fix use of ChecksumExtension in publishing.props
* Use the analyzer from the SDK when available
This prevents a build warning when building a project that contains a reference to
Microsoft.AspNetCore.Components and a netcoreapp3.0 or newer targeting Web project.
The Web SDK implicitly adds the Components.Analyzer for netcoreapp3.0 or newer targeting projects.
If the project additionally referenced this package (directly or transitively), the package would
set up a property that prevented the implicit analyzer reference. This prevented the analyzer from
being referenced twice.
There were two issues with the current approach:
a) The props file wasn't propogated via buildTransitive. Consequently transitive project references
would reference two copies of the analyzer. When these were different versions, it resulted in a compiler
warning.
b) Forward looking, this prevents newer versions of the analyzer shipped from the SDK from ever being used.
This is particularly problematic since apps are likely to reference component libraries that were previously
compiled against 3.x.
This change attempts to mitigate both of these issues:
a) We add a buildTransitive so our build targets flow
b) We knock out the analyzer added by the package if the SDK's already added it.
Fixes https://github.com/dotnet/aspnetcore/issues/18563
* Update Microsoft.AspNetCore.Components.Analyzers.targets
* Update Microsoft.AspNetCore.Components.Analyzers.targets
* Add a description
* Update Microsoft.AspNetCore.Components.Analyzers.targets
* Mark AspNetCore projects that aren't packaged explicitly
- avoid NU5104 warnings due to confusing versioning
- `$(IsShippingPackage)` was semantically incorrect in any case
* Remove redundant `$(IsShippingPackage)` settings in `$(IsAspNetCoreApp)` projects
- default is `true` for all implementation projects
* Use `$(IsPackable)` when deciding how `$(IsAspNetCoreApp)` projects are handled
- remove all use of `$(IsShippingPackage)` for shared framework composition
- update documentation to match these changes
nits:
- remove odd default for `$(IsPackable)` in Directory.Build.targets
- no longer relevant since all `$(IsAspNetCoreApp)` projects are `$(IsShippingPackage)` too
- include more information in docs/ProjectProperties.md
* Add direct System.Text.Json references
- avoid MSB3277 warnings
* [Platform] Detect and fix certificates with potentially inaccessible keys on Mac OS (2.1) (#17560)
* [Https] Detects and fixes HTTPS certificates where the key is not guaranteed to be accessible across security partitions
* Fix dotnet dev-certs https --check
* Update logic for detecting missing certs
* Fix security command
* Update warning logic
* Check that the key is accessible in Kestrel
* Add correct link to docs
* Update src/Tools/dotnet-dev-certs/src/Program.cs
Co-Authored-By: Daniel Roth <daroth@microsoft.com>
* Update src/Tools/dotnet-dev-certs/src/Program.cs
Co-Authored-By: Daniel Roth <daroth@microsoft.com>
* Add test for 2.1
* Update src/Tools/dotnet-dev-certs/src/Program.cs
Co-Authored-By: Chris Ross <Tratcher@Outlook.com>
* Address feedback
* Fix non-interctive path
* Fix tests
* Remove a couple of test from an unshipped product
* Check only for certificates considered valid
* Switch the exception being caught, remove invalid test
Co-authored-by: Daniel Roth <daroth@microsoft.com>
Co-authored-by: Chris Ross <Tratcher@Outlook.com>
* Fix patchconfig merge (#18389)
* Fix flaky HubConnectionHandler test (#18391)
Co-authored-by: Javier Calvarro Nelson <jacalvar@microsoft.com>
Co-authored-by: Daniel Roth <daroth@microsoft.com>
Co-authored-by: Chris Ross <Tratcher@Outlook.com>
Co-authored-by: Brennan <brecon@microsoft.com>
* Added the survey link to the Blazor Server project
* Use new survey link for server project
* Updated the baseline to include the SurveyPrompt.razor file
* Added the SurveyPrompt.razor to all the test baselines
* Add support for IAsyncEnumerable<T> where T is value type (#17154)
* Add support for IAsyncEnumerable<T> where T is value type
Fixes https://github.com/aspnet/AspNetCore/issues/17139
* Fixup ref asm
* undo changes to blazor.server.js
DotNet Bot
Javier Calvarro Nelson
Brennan
William Godbe
Doug Bunting
Ryan Nowak
John Luo
dotnet-bot
David Fowler
Pranav Krishnamoorthy
James Newton-King
Pranav K
Stephen Halter
Alessio Franceschelli
Jacques Eloff
dotnet-maestro-bot
Artak