* Ensure PackageArchive contains the right build of Razor.Design package
* Re-order values in build\dependencies.props to ensure Razor.Design's package version is
overwritten.
* Convert additional package refs to project refs
Fixes https://github.com/aspnet/AspNetCore-Internal/issues/1708
* Update CodeCheck.ps1
Possible fix to https://github.com/aspnet/AspNetCore/issues/7313
One of the characteristics of these failures were that the
test took long to run. The build log has warnings for
several long running tests. This might be a result of CPU
contention since mondo-ification that make MVC's functional tests
run with nearly every other test project in the solution
* Add some additional logging to ErrorPageMiddlewareWebSite
DeveloperExceptionMiddleware will log an error if rendering the exception page
throws. The test failure in https://github.com/aspnet/AspNetCore-Internal/issues/1730
suggests that we encountered an error like so but do not have anything further to go by.
This change adds logging to the test so we could identify possible issues
- 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
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.
Nate McMaster
Brice Lambson
Pranav K
dotnet-bot
Doug Bunting
Brennan Conroy
Doug Bunting
Stephen Halter
Matt Mitchell
Mikael Mengistu
Ryan Brandenburg
Ajay Bhargav Baaskaran
Chris Ross
Pavel Krymets
Nate McMaster
Justin Kotalik