* Rebase
* Remove Multi-Project Validator
* Remove projectmodelserver tests
* Enable test package creation
* Incremental test restore
* WiP
* Enable Test Asset Project restore
* Build Test Assets & Restore Test Projects
* Build Test projects
* Enable Test Execution
also moves Test Targets to a well-known CLI Version [Stage 2]
* Pass throuh existing telemetry profile
* 2-space tabs
* Revert TestTargets.cs
* WiP PR feedback
* Refactoring
* Fix naming of RestoreTestAssetPackages
* DotNetTest task
* Fix merge issue
* ExecuteWithCapturedOutput
MSBuild considers StdErr output to be failures. This causes output of any test command which is expected to produce an error to be swallowed in the test.
* Workaround for always-on tracing functionality in dotnet-test
* Fix Path Separator Windows/Unix
* Seperate package build from pack
* Windows Pathing issues
* PR Feedback
* Workaround for msbuild #773https://github.com/Microsoft/msbuild/issues/773
When building a project.json that has schema warnings (and other warnings), we are not writing the warnings to the console. This is a regression.
The fix is to add all diagnostic messages to the LibraryManager, which is responsible to hold all the diagnostic messages.
Fix 3021
The following packages are changing:
Microsoft.NetCore.App: 1.0.0-rc2-3002702 -> 1.0.0-rc3-002702
Microsoft.NETCore.DotNetHost: 1.0.1-rc2-002702-00 -> 1.0.1-rc3-002702-00
Microsoft.NETCore.DotNetHostPolicy: 1.0.1-rc2-002702-00 ->
1.0.1-rc3-002702-00
Microsoft.NETCore.DotNetHostResolver: 1.0.1-rc2-002702-00 ->
1.0.1-rc3-002702-00
Also publishing the *deb file to teh debian repo feed is disabled -
https://github.com/dotnet/cli/issues/2973
The issue is when the ProjectContextBuilder sees a CompileTimePlaceholder "_._" file on a full framework, it assumes that dependency has to come from the "Reference Assemblies" directory. If it can't be found there, an error is raised. However, there are other reasons "_._" placeholders are created (when a NuGet package doesn't want its dependencies to be exposed in the Compile dependencies of its consumers). And these placeholders can exist for assemblies that aren't in the full framework - in this case System.Diagnostics.FileVersionInfo and others.
To fix this, if the reference can't be resolved from the "Reference Assemblies" folder, it is just skipped. If the compiler really needs that assembly, it will raise an error to the user. Dotnet build shouldn't raise the error.
Fix#2906
