Simple removal of the build.proj file allows `dotnet` commands to just work without having to specify the sln file explicitly, which is really nice.
The build.proj was building all projects 3 times (build, test, and pack all rebuilt everything and repeated package restore, etc.), so it was slower than necessary anyway.
In its place:
1. folks can just use `dotnet build` or whatever command suits them.
1. Azure Pipelines simply executes dotnet commands, which I break up into 4 steps so the pipeline can show timings for each step, etc.
Because we use the Azure Pipelines DotNetCoreCLI task for running tests, the test results are automatically collected and reported as a searchable database.
Test results can be analyzed over time to see how they perform, which ones are unstable, etc.
The `UseDotNet` task is newer and follows best practices from the
dotnet SDK team better than the older `DotNetCoreInstaller` task.
One significant difference between the two is that `UseDotNet` sets
`DOTNET_MULTILEVEL_LOOKUP=0`, such that once you use this task once, you have to
manually install *all* SDK/runtime versions that your pipeline requires.
This task *may* be used more than once in order to accomplish this.
This is actually a *good* thing, because it means your pipeline is more fully
self-describing, and less dependent on whatever versions the agents happen to
have installed at the time.
Marco Rossignoli