- combine `RegexReplace` into `PrintTestRunSummary` task
- remove unused `WarnOnNoMatch` parameter; inline other parameters
- capture test summary in `msbuild` logs
- avoid `System.Console` use in the task
- fail task if any tests fail
- collect `xunit` task exit codes in case of catastrophic problems (not test failures)
- fail build if `PrintTestRunSummary` doesn't but errors occurred
also:
- do not test assemblies in parallel; reduce port contention issues
- avoid `CallTarget` task
nits:
- clean some trailing whitespace in C# sources
- mostly files I expect to update soon
- reduce `NuGet.exe restore` verbosity; no longer debugging that
- add console summary when using build.cmd
- reduce duplication in `RestorePackages` target
- only restore NetCore projects when `$(BuildPortable)` is `true`
- restore src NetStandard project transitively through NetStandard.Test project
- pass more properties w/ `Restore` target invocation
- add azure-pipelines.yml
- clean workspace when checking out the repo
- build about the same matrix as we have on TeamCity in Main.Integration builds
- run tests only in Release job by default
- do component governance work only in Release job
- do not inject CodeQL3000 tasks (when building main)
- publish test results
- jobs usually take less than 10 minutes
- change build.cmd to enable overrides of its command line parameters
nits:
- touch up .codeql.yml to avoid test code and include portable projects
react to a smallish breaking change in newer Owin packages
- add new test of `%` decoding to URI
- do not restore RuntimePortable.sln directly
- NuGet.exe is no longer happy w/ that solution
- ignore binary logs
- ensure the .NET Core 2.1 VS component is installed
- allow use of any 2.1.5xx .NET SDK
- add a few words to code analysis dictionary
- exclude files generated for `net45` legacy projects don't cause problems when compiling for `netstandard2.0`
- handle additional `ReflectionTypeLoadException`s when using the xUnit `msbuild` runner
nits:
- capitalize "MSBuild" consistently
- reduce indentation slightly
- no need to get things working where VS 2019 preview is the only build available
- start using .NET Core SDK 2.1.403
- confirmed AppVeyor and wsr-tc agents both have this SDK
- correct ordering issue with restore of System.Net.Http.Formatting.NetCore project
- change `CultureUtilTest` to use `Thread.CurrentThread`
- when hosted in latest MSBuild, changing `thread.CurrentThread` changes `Thread.CurrentThread` instead
- find current Microsoft.Build.Tasks assembly in WebStack.tasks.targets, not just the WebApiHelpPage project
- add `$(TestInParallel)`
- allows user to e.g. build in parallel but test assemblies serially
- default remains doing everything in parallel
- change build.cmd to set %ErrorLevel% when exiting
- add empty top-level Directory.Build.* files
Use only VS 2017 or later
- ensure same MSBuild features are available in command-line and VS builds
- move `$(MinimumVisualStudioVersion)` project settings to global location and bump required version up
Use Microsoft.NET.Sdk and `<PackageReference/>`s in .NET Standard project
- create a "real" .NET Standard 1.1 assembly, not .NET Portable v5.0
Move to latest version of the xUnit MSBuild runner
- v2.3.0 has a few bugs related to XML results files e.g. xunit/xunit#1515
- switch to current XML results format (required with v2.3.0 but doesn't hurt with later versions)
- make runner discovery version-independent
- add support for `msbuild /t:test` in test project directories
- bring System.Net.Http in from .NET Standard Library
- use .NET Standard version of Newtonsoft.Json
- bring other dependencies in transitively
- create initial test project, mostly a duplicate of existing "NetCore" one
nits:
- write detailed information to msbuild.log
- clean up trailing whitespace in a couple of test classes
- we don't support .NET 4.0 and shouldn't build or test using the older
target framework
- testing is particularly problematic since some unit tests fail due to
.NET 4.0 quirks (legacy System.Uri behavior in particular)
- part 1 of fixes for #1960
- Prefer VS 2013 (v12.0) version of MSBuild.exe and fallback to v4.0 when necessary
- Do not rely on %Path% since that limits us to VS developer cmd windows
- Match Microsoft.Build.Tasks*.dll version to MSBuild.exe, not type of cmd window
- Have tested building in VS 2013, VS 2013 dev cmd window, and bare cmd window
Requires either a FxCopCmd.exe.config binding redirect or David's "VS2013 FxCop
compatibility" change for full VS 2013 support.
Doug Bunting
Doug Bunting
Doug Bunting
davidmatson
anurse
bradwilson
bradwilson