Reimplement the MSBuild VSTestTask task based on ToolTask

[mcartoixa]

Description

The MSBuild ToolTask class was designed to help create custom tasks that wraps a command line tool, which is exactly what VSTestTask does (it wraps dotnet.exe exec vstest.console.dll). Using it allows to delete unneeded code while fixing #680.
The console output lost its colorized output (which was expected) but the task gained the ability to be logged.
A bit of maintenance was performed as well, making use of boolean properties where needed (instead of strings), and of ITaskItems for paths (instead of strings as well). Those changes should be compatible with existing usage though.
Unit tests have been refactored as well along the lines of the new implementation (and are all green, obviously). A real world test has been performed on a project of mine that was affected by #680, on Windows 10 only.
This might need further real world testing.

Related issue

Fixes #680

[msftclas]

All CLA requirements met.

[mcartoixa]

I don't seem to be able to execute the failling test on my computer (Visual Studio or CLI) and I fail to see how those are related to my changes. Please advise.

[nohwnd]

The console output lost its colorized output (which was expected)

Hmm that's a blocker IMHO. We want out colored output even when running from dotnet test.

[nohwnd]

Would re-run the pipeline, but it has conflicts. I don't see how the failing test would be related to your changes either.

[mcartoixa]

There was no conflict 4 days ago... I'll try and fight my way through git to resolve this (I may learn 1 or 2 things along the way 😁).
MSBuild always had its own coloring scheme (blue for projects, light gray for command lines, dark gray for command output...) and overriding this would require developing a special case. Note that messages output to the error console show up in red (and obviously fail the task).

[nohwnd]

There was no conflict 4 days ago... I'll try and fight my way through git to resolve this (I may learn 1 or 2 things along the way 😁).

You just need:

# add a remote pointing to the original repo 
# (this is usually called upstream), while your fork is called origin
git add remote upstream  https://github.com/microsoft/vstest.git
# update your forks master to our master
git checkout master
git pull upstream master
# merge your master to your PR branch 
git checkout vstesttask
git merge master
# solve conflicts
... <solve>
git add 
git commit -m"Merge master"
# push to update the PR
git push

That said, I don't think this would get merged if we would lose the colors.

[nohwnd]

😁 I love the just followed by 20 git commands

[mcartoixa]

Thanks. I went with a rebase (along the lines of https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request).
You may want to check that I have not messed up too much with your latest commit (I changed some properties to boolean to be consistent with the rest of my PR. You could even use enums for the DumpType arguments...).

As for the color, as I wrote it is inconsistent with MSBuild, but if you insist I'll see what I can do.

[mcartoixa]

From what I can gather it is not possible to log and keep the colored output. You need to choose:

• ProcessStartInfo.RedirectStandardOutput (on which ToolTask is based) redirects only the textual output.
• There might be a way to implement a custom console redirection routine using the ReadConsoleOutput Windows API, but it seems daunting enough for Windows: I cannot imagine myself handling this stuff cross platform.

Please note that in the case of #680 the reporter would be (understandably IMHO) more interested in a searchable log than in a colored output, and that in my use case (MSBuild on AppVeyor) I don't even have a console output: only a log, which is empty.

[pavelhorak]

Closing this PR since it would affect expected color output.