* 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.
* Rename centralized LocalizableStrings file
* Added RemoveDefinition
* Rebase
* rebase, remove localizablestrings for help
* loc for help command
* remove localizablestrings
* Localization changes for dotnet-remove
* Slight refactoring
* 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
* Localization for dotnet-clean command.
* Modified spacing to keep under the 120 char limit
Moved the parameters of each option to a new line.
* Moved projectArgument parameter to a new line
* Add InstallDir to path if SDK version is already installed
* Make changes based on feedback
* Rename "Append" to "Prepend"
* Remove check if directory is already in path
* Snap of sln reader/writer from https://github.com/mono/monodevelop
* Remove unnecessary code
* Create a new test asset with an sln file because adding an sln to an existing one broke other tests
* Remove commented out line
* Removing unneeded PropertyGroup per PR comments
* Update the license
* Fixing the license
* Fix 4066
* Merge Conflict
* Move fix to the DotNetCommandFactory
* More normalization
The `\r\n` issue is oddly non-deterministic. This change did not affect the message endings and yet CI started failing. Normalizing both string should have the desired result...
* update web template
* add test build of fsharp/web template
* align fsharp/xunittest template
* add test for all template projects
* align fsharp/console template to #4821
* align fsharp/lib template to #4821
* align fsharp/mstest template to #4821
* align fsharp/xunittest template to #4821
* fix shortened test directory path (was same for c# test)
* try fix ci failure
* Bug fixes
* Nitpick
* -Fixed failed tests
-Added test to cover trx logger scenario.
* Fix for issue https://github.com/Microsoft/vstest/issues/241
* Fix for failed test. We have taken fix where dotnet test will return nonzero if test fails. In multi TFM scenario if test fails it termates the whole process as dotnet test is returning 1. As a fix of this we should continue if some test fails for next TFM
* Bump Microsoft.Testplatform.CLI and Microsoft.NET.Test.Sdk version
* Checking that the lock file exists before trying to acquire a lock for it, which takes up to 30 seconds.
* Adding a test for failing when reading the lock file and it does not exists.
