This pull request updates the following dependencies
[marker]: <> (Begin:Coherency Updates)
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **System.Net.Http.WinHttpHandler**: from 4.7.0 to 4.7.1 (parent: Microsoft.NETCore.App.Runtime.win-x64)
[marker]: <> (End:Coherency Updates)
[marker]: <> (Begin:7bf32a0c-3505-43af-42b0-08d79559e63d)
## From https://dev.azure.com/dnceng/internal/_git/dotnet-aspnetcore-tooling
- **Subscription**: 7bf32a0c-3505-43af-42b0-08d79559e63d
- **Build**: 20200422.2
- **Date Produced**: 4/22/2020 7:47 PM
- **Commit**: a8242d79df31dbff528c185dd62c290b7cc262de
- **Branch**: refs/heads/internal/release/3.1
- **Updates**:
- **Microsoft.AspNetCore.Mvc.Razor.Extensions**: from 3.1.4 to 3.1.4
- **Microsoft.AspNetCore.Razor.Language**: from 3.1.4 to 3.1.4
- **Microsoft.CodeAnalysis.Razor**: from 3.1.4 to 3.1.4
- **Microsoft.NET.Sdk.Razor**: from 3.1.4 to 3.1.4
- **System.Net.Http.WinHttpHandler**: from 4.7.0 to 4.7.1
[marker]: <> (End:7bf32a0c-3505-43af-42b0-08d79559e63d)
This pull request updates the following dependencies
[marker]: <> (Begin:7bf32a0c-3505-43af-42b0-08d79559e63d)
## From https://dev.azure.com/dnceng/internal/_git/dotnet-aspnetcore-tooling
- **Subscription**: 7bf32a0c-3505-43af-42b0-08d79559e63d
- **Build**: 20200415.2
- **Date Produced**: 4/15/2020 6:12 PM
- **Commit**: a49970f2f15efb27b91541bb4b94581693c92b8d
- **Branch**: refs/heads/internal/release/3.1
- **Updates**:
- **Microsoft.AspNetCore.Mvc.Razor.Extensions**: from 3.1.4 to 3.1.4
- **Microsoft.AspNetCore.Razor.Language**: from 3.1.4 to 3.1.4
- **Microsoft.CodeAnalysis.Razor**: from 3.1.4 to 3.1.4
- **Microsoft.NET.Sdk.Razor**: from 3.1.4 to 3.1.4
[marker]: <> (End:7bf32a0c-3505-43af-42b0-08d79559e63d)
* 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.
This pull request updates the following dependencies
[marker]: <> (Begin:7bf32a0c-3505-43af-42b0-08d79559e63d)
## From https://dev.azure.com/dnceng/internal/_git/dotnet-aspnetcore-tooling
- **Subscription**: 7bf32a0c-3505-43af-42b0-08d79559e63d
- **Build**: 20200414.7
- **Date Produced**: 4/15/2020 5:37 AM
- **Commit**: 06ade7a064cbdcf80aa6457541c1a99b7e39b5a8
- **Branch**: refs/heads/internal/release/3.1
- **Updates**:
- **Microsoft.AspNetCore.Mvc.Razor.Extensions**: from 3.1.3 to 3.1.4
- **Microsoft.AspNetCore.Razor.Language**: from 3.1.3 to 3.1.4
- **Microsoft.CodeAnalysis.Razor**: from 3.1.3 to 3.1.4
- **Microsoft.NET.Sdk.Razor**: from 3.1.3 to 3.1.4
[marker]: <> (End:7bf32a0c-3505-43af-42b0-08d79559e63d)
[marker]: <> (Begin:Coherency Updates)
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Microsoft.AspNetCore.Analyzer.Testing**: from 3.1.4-servicing.20181.5 to 3.1.4-servicing.20202.2 (parent: Microsoft.EntityFrameworkCore)
- **Microsoft.AspNetCore.BenchmarkRunner.Sources**: from 3.1.4-servicing.20181.5 to 3.1.4-servicing.20202.2 (parent: Microsoft.EntityFrameworkCore)
- **Microsoft.Extensions.ActivatorUtilities.Sources**: from 3.1.4-servicing.20181.5 to 3.1.4-servicing.20202.2 (parent: Microsoft.EntityFrameworkCore)
- **Microsoft.Extensions.CommandLineUtils.Sources**: from 3.1.4-servicing.20181.5 to 3.1.4-servicing.20202.2 (parent: Microsoft.EntityFrameworkCore)
- **Microsoft.Extensions.HashCodeCombiner.Sources**: from 3.1.4-servicing.20181.5 to 3.1.4-servicing.20202.2 (parent: Microsoft.EntityFrameworkCore)
- **Microsoft.Extensions.HostFactoryResolver.Sources**: from 3.1.4-servicing.20181.5 to 3.1.4-servicing.20202.2 (parent: Microsoft.EntityFrameworkCore)
- **Microsoft.Extensions.Logging.Testing**: from 3.1.4-servicing.20181.5 to 3.1.4-servicing.20202.2 (parent: Microsoft.EntityFrameworkCore)
- **Microsoft.Extensions.ParameterDefaultValue.Sources**: from 3.1.4-servicing.20181.5 to 3.1.4-servicing.20202.2 (parent: Microsoft.EntityFrameworkCore)
- **Microsoft.Extensions.TypeNameHelper.Sources**: from 3.1.4-servicing.20181.5 to 3.1.4-servicing.20202.2 (parent: Microsoft.EntityFrameworkCore)
- **Microsoft.Extensions.ValueStopwatch.Sources**: from 3.1.4-servicing.20181.5 to 3.1.4-servicing.20202.2 (parent: Microsoft.EntityFrameworkCore)
- **Microsoft.NETCore.App.Internal**: from 3.1.4-servicing.20181.2 to 3.1.4-servicing.20202.1 (parent: Microsoft.Extensions.Logging)
- **Internal.AspNetCore.Analyzers**: from 3.1.4-servicing.20181.5 to 3.1.4-servicing.20202.2 (parent: Microsoft.EntityFrameworkCore)
- **Microsoft.AspNetCore.Testing**: from 3.1.4-servicing.20181.5 to 3.1.4-servicing.202 ...
**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
* Attempt to auto-publish vs.redist packages to orchestrated feed
* Use non-stable packageVersion for vs.redist
* Fix typo
* Update build/Publish.targets
- should trigger a build that's more likely to succeed
* Print what we're trying to publish
* More debug prints
* Set RedistPackageId in publishing.targets
* Reference variable correctly
* Remove unnecessary messages
* Respond to feedback
Co-authored-by: Doug Bunting <6431421+dougbu@users.noreply.github.com>
Will Godbe
John Luo
DotNet Bot
dotnet-bot
David Fowler
Brennan
Pranav Krishnamoorthy
dotnet-maestro[bot]
Pranav K
Doug Bunting
Matt Mitchell
James Newton-King