- correct `--filter` syntax; perform `contains` match on `Name` and not `FullyQualifiedName`
- `FullyQualifiedName` doesn't seem to include NUnit test case data
- move to latest test package versions
- support recent SDK versions
Background: successful but no-op builds have been common lately
- blocking real work on aspnet/AspNetCore-Internal#1843
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.
This refactors the targets used to build the shared framework and its .zip files. There are lots of reasons motivating this: Arcade convergence, migration to VSTS, making it easier to build this locally, etc.
Changes:
* Moves move content of build/Sharedfx.{props/targets} into eng/targets/SharedFx.Common.{props/targets}
* Update the build to produce a `runtime.$rid.Microsoft.AspNetCore.App` package (not just the one with symbols in it)
* Refactor the targets which produce .tar.gz/.zip files into separate projects in `src/Installers/`
* Refactor installers, unit tests, and the framework projects to use ProjectReference to flow dependencies between different parts of the build.
* Makes it easier to build the shared framework locally (for the inner dev loop, you can run `dotnet build -p src/Framework/Microsoft.AspNetCore.App/src/ -r win-x64`)
Changes:
* Add a test project with simple unit tests for the shared framework
* Add root-level Directory.Build.props/targets files
* Cleanup .csproj files to reduce duplication
Changes:
* Add a test project with simple unit tests for the shared framework
* Add root-level Directory.Build.props/targets files
* Cleanup .csproj files to reduce duplication
Doug Bunting
Matt Mitchell
Nate McMaster
Mikael Mengistu
Nate McMaster
Ryan Brandenburg
Mike Harder