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.
For a perfectly clean repo (git clean -fdx), `dotnet build` fails because some tests require that other projects have been built using build.proj first.
This change adds the necessary build ordering instructions so that the build tasks are always built before the tests that need them, and the tests are always run against the *latest* source code being tested rather than the last version that happened to be built with build.proj.
All the redundancy between the .nuspec file and the .csproj file (both express and implied) is now removed. With it, I fix a few bugs:
1. The generated nuspec file includes the developmentDependency tag that was in the project file but not the checked in file.
1. The package now applies to *all* projects regardless of their target framework (well, so long as they're .netstandard1.0 compatible) instead of all projects rejecting this package unless they targeted .NET Core 2.0 or higher.
I also moved the .targets file into a folder structure within the project that resembles where it will appear in the package. This makes it more obvious that it belongs to the package when looking at the source code, and makes it easier to maintain the build/ folder in the package going forward because all files in it are included.
Fixes#431
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.
Toni Solarin-Sodara