-
Notifications
You must be signed in to change notification settings - Fork 323
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VSTestTask
only logs to the console
#680
Comments
@dougbu can you elaborate little more on the scenario? Is the user intention to customize/diagnose build parameters for vstest task? Is it in the CI or devbox? Can the stdout/stderr redirection with |
The scenario is diagnosing test failure, reviewing what the tests output. If diagnosing the task parameters were of interest, the minimal logging from the task would be useful. This is on a developer's machine. By default, we run our command-line builds with a file logger for detailed output. The log file is very useful for searches, reviewing data lost in screenfulls of output, and occasionally for the extra MSBuild info. Turns out the log file is useless for reviewing or diagnosing tests failures. Redirecting the output works but isn't particularly helpful. That requires additional test runs and usually comes after wasting time looking at the log file. Bottom line, |
Thanks for clarification. We need to wire this in. Possibly use |
Bump. My tests work fine on my machine but fail on the build server (AppVeyor). There I can only access the MSbuild logs, and as there is no output I am completely blind... .NET Core 3.0 preview 7 BTW I have some experience with MSBuild tasks and may be able to contribute. Can I submit a PR directly? |
Anyone? I have tried to base So no PR. Instead, please find a largely untested Gist: https://gist.github.com/mcartoixa/8c001df6fec75cfa95ad33d693df8fc5. The |
Bump |
Anybody in there? |
@pavelhorak we should do something about this but my plate is full right now. This imho needs a triage and might be affected by this change dotnet/sdk#11379. @mcartoixa testing against a build of dotnet sdk takes a bit of effort. Based on where you need to do your changes you might be able to use a pre-build sdk installed via dotnet/installer and just patch the build task and point it to a difference vstestconsole dll using the VSTestConsolePath msbuild parameter. Or you might need to build the whole dotnet/sdk and use their eng/dogfooding.cmd to start a powershell session with the correct env variables. There you can copy the correct task definition and also point it to the correct vstest console dll. Copying the artifacts from vstest repo to the dotnet installation in fact does not work. Line 269 in df61f73
You can override the path to the task dll and console dll by using those params: Specified as:
(Might be obvious, but let's point it out. this won't work with dotnet vstest or dotnet test + dll because those don't call msbuild.) Hope this will help you investigate further. |
@nohwnd Thanks for the ❤️! If I remember correctly the only fix is to base the task on ToolTask which takes care of the logging (and is the right thing to do anyway). I will try and set up a test environment for my fix. I am much more experienced in MSBuild than in PRs though: do you want a PR based on the current master? |
@nohwnd FYI I have just got bitten hard by a strange (?) behavior: I've got to quite some trouble to customize In short, it seems that |
Also refined the use of boolean types in the MSBuild targets.
It seems we have a problem with PR #2437 because:
I know I am very late to this game and that there are complexities involved that I do not understand but if you would indulge me for a bit anyway my suggestion would be:
I believe achieving this would give a more consistent experience, and give more choice to developers. But:
Let me know what you think. I may be of help if I can (and if you are interested). |
Slow days at work, so here what I intend to do:
|
If the $(VSTestUseConsole) property is set to True during the build, the old console forwarding VSTestForwardTask is used.
If the $(VSTestUseConsole) property is set to True during the build, the old console forwarding VSTestForwardTask is used.
If the $(VSTestUseConsole) property is set to True during the build, the old console forwarding VSTestForwardTask is used.
If the $(VSTestUseConsole) property is set to True during the build, the old console forwarding VSTestForwardTask is used.
This bug is nearly 5 years old now. Its root causes have metastasized bugs in different repositories (#1503, #2224, #2953, dotnet/msbuild#5387, dotnet/sdk#9481 are some could gather). #2702 should help clean the whole thing up but is more than a whole year old at this point. What would be nice would be some sense of visibility about the future. Is a fix going to make its way in 2022? .NET 8 perhaps? |
If the $(VSTestUseConsole) property is set to True during the build, the old console forwarding VSTestForwardTask is used.
If the $(VSTestUseConsole) property is set to True during the build, the old console forwarding VSTestForwardTask is used.
If the $(VSTestUseConsole) property is set to True during the build, the old console forwarding VSTestForwardTask is used.
I am still struggling with this, years later. Tests work fine on machine but fail on the CI server. Check the logs:
Thanks for nothing, and good luck with that. The most frustrating thing is to know that there has been a fix waiting in the limbo for the last 18 months (#2702). |
If the $(VSTestUseConsole) property is set to True during the build, the old console forwarding VSTestForwardTask is used.
If the $(VSTestUseConsole) property is set to True during the build, the old console forwarding VSTestForwardTask is used.
VSTestForwardingTask redirects the console output instead of using MSBuild logs. Renaming it will allow to create a new VSTestTask that uses the MSBuild log infrastructure.
…ild infrastructure (microsoft#680) This new task will be used by default during the build. If the $(VSTestUseConsole) property is set to True, the old console forwarding VSTestForwardTask will be used instead.
VSTestForwardingTask redirects the console output instead of using MSBuild logs. Renaming it will allow to create a new VSTestTask that uses the MSBuild log infrastructure.
…ild infrastructure (microsoft#680) This new task will be used by default during the build. If the $(VSTestUseConsole) property is set to True, the old console forwarding VSTestForwardTask will be used instead.
VSTestForwardingTask redirects the console output instead of using MSBuild logs. Renaming it will allow to create a new VSTestTask that uses the MSBuild log infrastructure.
…ild infrastructure (microsoft#680) This new task will be used by default during the build. If the $(VSTestUseConsole) property is set to True, the old console forwarding VSTestForwardTask will be used instead.
VSTestForwardingTask redirects the console output instead of using MSBuild logs. Renaming it will allow to create a new VSTestTask that uses the MSBuild log infrastructure.
…ild infrastructure (microsoft#680) This new task will be used by default during the build. If the $(VSTestUseConsole) property is set to True, the old console forwarding VSTestForwardTask will be used instead.
* Rename VSTestTask to VSTestForwardingTask (#680) VSTestForwardingTask redirects the console output instead of using MSBuild logs. Renaming it will allow to create a new VSTestTask that uses the MSBuild log infrastructure. * Refactor the VSTestForwardingTask to use the MSBuild infrastructure (#680) * Create a ToolTask based VSTestTask that integrates nicely in the MSBuild infrastructure (#680) This new task will be used by default during the build. If the $(VSTestUseConsole) property is set to True, the old console forwarding VSTestForwardTask will be used instead. * Initialize the VsTestUseConsole property during acceptance tests The `$(VSTestUseConsole)` should be set to `True` when running the `dotnet test` command to keep the legacy behavior. Adding it during the tests for now: it should be set in the command itself eventually. * Fix various issues raised by the latest review * Simplify the handling of null values * Log messages to MSBuild instead of to the console * Integrate changes from the latest code review * Patch dotnet with newest build task * wip * rnm * revert tests * tests * Try adding msbuild specialized logger to output errors on tests * Use simpler logger * wip * fix no-source * fix no-source * add message for full error * Revert playground * Revert console logger * Revert integration tests * Revert change in integration tests * Fix test * Revert test unignore --------- Co-authored-by: Jakub Jareš <me@jakubjares.com>
This was addressed in #2702 |
Description
File logging output contains information about calling the
VSTestTask
but no output from the task itself. This makes it difficult to search the test's output.Steps to reproduce
Appears to occur with every ASP.NET repo. For example,
git clone https://github.com/aspnet/HtmlAbstractions.git
cd HtmlAbstractions\test\Microsoft.Extensions.WebEncoders.Tests
dotnet restore
dotnet build
dotnet test --no-build --framework netcoreapp2.0 /flp:verbosity=diag
notepad msbuild.log
Expected behavior
Same information in the
msbuild.log
file as was shown on the console:Actual behavior
Information around the
VSTestTask
call but nothing from the task itself:Environment
Not sure how long this issue has been happening. We don't have MSBuild logs from that far back. The following describes my current environment.
Please share additional details about the test environment.
dotnet --info
Operating system, Build version of vstest.console
Logging above mentions
"C:\Users\dougbu\AppData\Local\Microsoft\dotnet\sdk\2.0.0-preview1-005418\Microsoft.TestPlatform.Build.dll".
The text was updated successfully, but these errors were encountered: