- 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.
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
Mike Harder