* update nuget to 4.0.0-rc3 and sdk to 1.0.0-alpha-20170105-5
* Modifying restore project.json to use the project.json stage0 CLI instead of restore-projectjson command.
* add a nuget dependency so migrated project has packageref and generates an assets file on restore
* Archive asp.net package references
* Archive asp.net package references
* Change the hash input so it's the same on all platforms
* Address PR comments
* add stub for dotnet list p2ps
* apply review feedback
* PR feedback: consistent method modifiers
* apply missed review feedback
* add test coverage and do not treat no p2ps as error
* move private methods to the bottom, rename weird res name
* Move dotnet-new templates to Sdk attribute
* Update to MSBuild 15.1.0-preview-000454-01
To pick up a fix for Microsoft/msbuild#1431.
* Fix template newlines
* Fix casing on Microsoft.Net.Sdk
* Move migration test csproj's to Sdk attribute
* Disable parallel sdk restore
Each SDK restore operation will try to manipulate the same assets.json file since the dependency name&version are injected into a common csproj file. This can cause runtime failures when two NuGets try to restore the project at once.
* Make casing of SDK 'NET' and not 'Net'
* Remove redundatn imports
* Fix test string
* Additional race
* Replacing the SDK with the Web.Sdk when it is a Web project.
* Fixing the test by writting the csproj before running the migration rule.
* Fix output race
TestCommand starts the test process before wiring up stderr & stdout. This change delays process start until after the wireup is finished so that the test process cannot shut down before we have wired up output redirection.
* Bypass stream forwarder when it fails to attach to a process
CLI has tests failing errenously when, due to timing issues, the StreamForwarders fail to attach to a process because it managed to exit before attachment occurs.
We tried attaching the forwarders prior to Process Start but this proved impossible because the OUT and ERR streams are not available to attach before the process starts.
This exposes a fundamental flaw in our output redirection mechanisms. We should probably move to using https://msdn.microsoft.com/en-us/library/system.diagnostics.process.outputdatareceived.aspx or a similar mechanism. However, I don't know that @brthor hadn't considered and discarded this approach.
For the time being I am attempting to make tests more deterministic by capturing the associated exceptions and moving to a different mechanism when StreamForwarders are not available.
Opened https://github.com/dotnet/cli/issues/4913 to track the broader issue.
* File.Copy is not atomic...
* Centralize Microsoft.Net.Sdk package version
Note: Templates were omitted as their version needs to be static.
* Unifying additional missmatched versions
* prefercliruntime
whitespace threw off ReplaceAll
* Additional missed globs
* Revert SDK version for performance tests
* PR Feedback
* Roll back VSTestXunitDesktopAndNetCore.csproj SDK version
* WIP migrate tests
* WIP fixing more tests
* WIP fix test build break
* Test results files are now trx
* Get CI to pass until we get an xunit xml logger
* Added DotNetTestPJ since that was needed for one test
* Fix build break
* Forgot to add DotNetTestPJ as a build task
* Need to restore project.json for the project used in ubuntu test
* Restore PJ for ubuntu test
* Switch the Ubuntu test to csproj based
* Updating the Microsoft.Net.Sdk & Microsoft.Net.Sdk.Web versions
* Fixed merge conflicts. Had to re-update the Sdk version in one place.
* re-migrate dotnet.dll
* Revert Performance Test Projects
* Fix test test
* Add missing WithRuntime
* Disable failing test test
* Migrate "runtimes" section as a RuntimeIdentifiers property in the resulting csproj file. Also do not call restore3 from publish3 anymore.
* Fix up the publish3 tests to call restore3 first and the csproj files to have RuntimeIdentifiers
Moving the CommandResolution classes that depend on msbuild back into Cli.Utils.
Updating the src projects to a netstandard compatible with Cli.Utils moving to netstandard1.5
