Csc/Vbc Tasks should log stderr as error#27349
Conversation
|
Need to override the /// <summary>
/// Standard error output should be considered of high importance so that it shows up in even
/// minimal logs. This is how unhandled exception information is output by the runtime.
/// </summary>
protected override MessageImportance StandardErrorLoggingImportance => MessageImportance.High; |
| public ManagedCompiler() | ||
| { | ||
| TaskResources = ErrorString.ResourceManager; | ||
| LogStandardErrorAsError = true; |
There was a problem hiding this comment.
We should add a comment on why we are doing this. There isn't a great way to test this so need to have a comment justifying the change else deleting it will seem to be a fine change as it doesn't break CI
I think the easiest thing would be to produce the Microsoft.NET.Compiler.Core nupkg with your change and test using RTM CLI and a package ref to your nupkg. For a more out-of-the-box-like test, you could also download the zip https://www.microsoft.com/net/download/thank-you/dotnet-sdk-2.1.300-windows-x86-binaries and replace the sdk\2.1.300\Roslyn directory with your bits. |
|
@jcouv I validated this change locally. Here is the steps I took to validating.
|
|
@jaredpar If I understood correctly, Rainer's comment (see linked issue) indicated that only one of the fixes should be sufficient. I'll test and confirm. |
rainersigwald
left a comment
There was a problem hiding this comment.
You shouldn't need to also up the priority: error is always higher-than-high-pri.
|
Verified the fix using Jared's instructions. Now, the error is printed out (including the very long stacktrace in the overflow scenario). |
|
@jaredpar for second sign-off and for ask-mode approval for 15.8. Thanks |
@nguerrera Would you have some tips for setting up a CLI with a custom-build version of Roslyn, so that I can validate the fix?
Customer scenario
If you build a CLI project that causes the compiler to crash (for instance, stackoverflow on a very deep fluent expression, or any other crash), you get an error code, but not error message or stacktrace.
Bugs this fixes
Fixes #27248
Fixes dotnet/msbuild#3054
Workarounds, if any
It is possible to recover the details of the failure with the following steps;
buildcommand, but add the option for binary logging/bl(for example,dotnet build /bl)msbuild.binlogfile with the binary log viewer.Csctask (as shown below)repro.rsp, removing the first two chunks (the first one for "dotnet.exe" and the second one for "csc.dll")dotnet.exe csc.dll @repro.rspRisk
Performance impact
Low. We're just setting an option for how the MSBuild ToolTask reports on outputs to
stderr. The compiler doesn't normally output tostderr.Is this a regression from a previous update?
No.
How was the bug found?
Reported by customers.
Tagging @rainersigwald @jaredpar