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
When running an app with `dotnet run`, we are redirecting the standard out and error just to print it out to our standard out and error. However, we are batching the output until we hit a newline, which isn't ideal for console apps.
To fix this, `dotnet run` no longer redirects the standard out and error.
Fix#2777
This is required to update the corefx dependencies from RC2 to RC3. Some
of the corefx libs have 'netstandard1.6' as TFM and this version of Nuget
supports that TFM.
Also the 'VersionRange.IncludePrerelease' has been removed from nuget and by
default 'VersionRange.Satisfies' returns true for any prerelease version.
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
* Throw Command Unknown for dependency tools in libraries.
* Add testProjects to test tools command for libraries.
* update failing tests
* Add tests verifying that dependency tools are not available in libraries
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
Simple tests which does static analysis of managed assemblies metadata to
make sure that they are crossgened. Currently it verifies that all the
assemblies in CLI SDK and SharedFx directroty are crossgened.
Creates a TestDirectory abstraction under TestInstance to manage creation of test-specific working directories
Enables TestAssetManager to create TestDirectory instances
Enables fluent addition of Environment Variables to TestCommand
Adds PathUtility support for ensuring a directory exists
* Add script to run and compare CLI perf tests
tests/Performance/run-perftests.py is a Python3 script that fetches all
of the dependencies needed to run the perf tests in test/Performance
locally. It can run the perf tests for a single dotnet.exe, or run two
dotnet.exe instances sequentially and compare the results between them.
Basic usage for a single test:
run-perftests.py --name "runid" ...\dotnet.exe
Usage for a comparison run:
run-perftests.py --name "runid" ...\dotnet.exe --base ...\dotnet.exe
For more detailed usage:
run-perftests.py -h
* run-perftests: fix publish xunit.perf.runner.cli
The code that builds xunit-performance would skip publishing
Microsoft.DotNet.xunit.performance.runner.cli due to a bug in the
condition to check whether it was published already or not. To fix the
issue and simplify the logic, I'm making it always publish when
building the project, instead of building and publishing separately.
* run-perftests: add support for python2
* run-perftests.py: fix framework version issue
The perf test harness was failing with "stage 0" binaries due to an issue
finding the correct installed framework version. The fix is to delete the
project.lock.json followed by a dotnet restore before each run, using the
dotnet.exe that is about to be tested. (Kudos to @brianrob for the debugging
help and suggested fix!)
The BuiltInCommandTests sets the current Console.Out and Console.Error, which causes the test to fail if some other test is running and writes to the console at the same time.
Fix#2768
