- new version
- update baselines
- grab latest released Microsoft.NetCore.App and Microsoft.NETCore.DotNetAppHost
nit:
- updated ZipManifestGenerator's README.md to use 2.2 examples
- aspnet/AspNetCore-Internal#1735
- port aspnet/Extensions@e2bb8ac1a0 fix into this repo
- change `default-build.yml` instead of `azure-pipelines.yml`
- make a couple of changes to `KillProcesses.ps1` (which I'll take back to Extensions)
- remove `ci-official.yml`
- aspnet/AspNetCore-Internal#1341
- remove Scaffolding references from `build/artifacts.props`, `build/buildorder.props`, `build/submodules.props`, and our templates
- add versions for these packages in `build/dependencies.props` to enable their inclusion in the package archives
* Put Razor.Design.Test and Razor.Language.Test in a different test group (#6725)
* Move dotnet watch to a seperate test group (#6730)
* Reuse root `version.props` in Templating
- do not let Templating get behind branding changes
* Revert "Put Razor.Design.Test and Razor.Language.Test in a different test group (#6725)" (#6753)
This reverts commit 563ff7c639.
* Revert file watch test changes
* Fix#6102 - Intense CPU utilization on page change
The issue here was that every time a Razor Page changed, we would
subscribe an additional time to the endpoint change notifications. This
means that if you tweaked a page 30 times, we would update the address
table 31 times when you save the file. If you were doing a lot of editing
then this would grow to a really large amount of computation.
The fix is to use DataSourceDependentCache, which is an existing utility
type we developed for this purpose. I'm not sure why it wasn't being
used for this already. We're already using DataSourceDependentCache in a
bunch of other places, and it's well tested.
I also tweaked the stucture of this code to be more similar to
EndpointNameAddressScheme. This involved some test changes that all
seemed like good cleanup. The way this was being tested was a little
wonky.
(cherry picked from commit a5658a8c95)
The 2.0 version of the Microsoft.Extensions.DependencyModel does not
support the assembly/file version metadata. We must have at least 2.1.
Between 2.1.6 and 2.1.7, we switched the build to use MSBuild.exe
("full" MSBuild) instead of `dotnet msbuild` ("core" MSBuild). MSBuild
has different assembly loaders behaviors in core vs full. By switching
MSBuild types, we were also unintentionally switching the version of
Microsoft.Extensions.DependencyModel.dll that was being used by our build
task from 2.1 back down to 2.0.
The reason we didn't discover this in earlier 2.1.x patches is that
building on msbuild core automatically upgraded our build tasks to
Microsoft.Extensions.DependencyModel.dll, Version=2.1.0.0. This happens
because of differences in the way .NET Core and MSBuild handles
assemblies with the same ID and different versions, and differences in
the layout of MSBuild and the .NET Core CLI.
In the end, this happened because we didn't have test coverage. MSBuild
and custom tasks burned asagain, but we should have just had unit tests
all along, which would have uncovered this regression as soon as we
switched to msbuild.exe.
Doug Bunting
James Newton-King
BrennanConroy
Stephen Halter
Pavel Krymets
Doug Bunting
Pranav K
Javier Calvarro Nelson
Murat Girgin
Chris Ross
John Luo
Nate McMaster
Ajay Bhargav Baaskaran
Ajay Bhargav Baaskaran
Justin Kotalik
Ryan Nowak
Nate McMaster