Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Simplify the build process & scripts (#648)
* Remove old debris Apparently, the build script used to compute code coverage, but this has been disabled for a long time and would probably take some work to bring up-to-date again. Let's remove this for now and add it back once we have cleaned up the build process. SourceLink verification has been disabled because it doesn't work well while one is working locally. Let's remove it and bring it back once we have cleaned up the build process. The CI server (AppVeyor) is set up to push packages to NuGet, and this is how packages should be published. Most users of this build script wouldn't be able to use `Publish` anyway because they do not know the NuGet API key required for pushing. So, remove this target lest people think that they *should* be able to use it. Also, remove obsolete entries from `.gitignore`. * Separate project for AppVeyor build version update ... which we trigger from `appveyor.yml`. While we're at it, change the format used for AppVeyor build versions to use something a little more unique. The version scheme used so far frequently caused version collisions (and unnecessary build warnings) e.g. when force-pushing changed commits on a PR branch. * Delegate `Test` target to test projects Currently, `build.proj` restores xUnit-related packages which is not actually necessary, since the unit test projects already require them. Moving the responsibility of running tests to the test projects them- selves makes this much clearer and means that the build script won't have to do redundant work. * Use `Pack` target instead of `nuget pack` * Use MSBuild-integrated package restore This finally makes an external `nuget` tool obsolete, which lets us remove a ton of build script stuff. * Extract basic assembly info into shared `AssemblyInfo.props` * Extract GitInfo build parts into `GitVersion.props` * Extract SourceLink build parts into `SourceLink.props` (The reason why we're specifying that SourceLink should not run if building from inside Visual Studio is that SourceLink produces some garbled output in the 'Output' window there that cannot be easily suppressed.) * Extract xUnit build parts into `xUnit.props` * Extract strong-naming build parts into `SignAssembly.props` * Replace `dotnet xunit` with `dotnet test`, then upgrade to xUnit 2.4 xUnit 2.4 has abandoned the `dotnet-xunit` CLI tool which we rely on to run our unit tests. We cannot keep using `dotnet-xunit` if we want to be able to upgrade xUnit, so let's get rid of it now. Alternatives considered: * `xunit.runner.msbuild` would seem like the obvious choice, but it is not cross-platform since it only targets .NET 4.5. * `xunit.runner.console` would be the next best thing, since it is as feature-complete as `dotnet-xunit` (e.g. it can generate HTML and XML test run reports and knows about options like `-noshadow`) but it's excruciatingly hard to call, since it comes in various versions and we need to map the current `<TargetFramework>` to an appropriate command line. Unfortunately, MSBuild multi-targeting does not work automatically for `<TargetFrameworks>` and we'd need to perform some MSBuild contorsions / recursion to get there. * `dotnet test` works well with multi-targeting, but doesn't have all options that we've used up until now. Let's go with the last one for simplicity's sake. If we get complaints about missing test run report files, we can go back to the more stren- uous `xunit.runner.console`. * Remove `build.cmd` and `build.proj` We have got `build.proj` to a point where it does only few things: 1. sets default build targets via `<Project @DefaultTargets>` 2. invokes MSBuild on the solution or projects for each target 3. creates and deletes the `out/` directory 4. specifies the dependencies between the targets All of these except (1) can be done without a dedicated build project, and (1) isn't crucial since we can just set the build targets e.g. in `appveyor.yml`. For command line execution, the MSBuild default target `Build` will often be good enough. * Normalize whitespace to tabs * Add CoreBuild Standard badge to README
- Loading branch information
