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
Moves CLI version suffix from preview1 to preview2
Sets channel for preview2 to 1.0.0-preview2, abandoning the Beta channel to the 1.0.0-preview1 release. Once @sokket's publishing cleanup work is complete we can re-converge the channels if desired.
* 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
