search

dotnet / msbuild

The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
https://docs.microsoft.com/visualstudio/msbuild/msbuild
MIT License
5.21k stars 1.35k forks source link

Cross-targeting projects emit difficult to diagnose errors #4361

Open ericstj opened 5 years ago

ericstj commented 5 years ago

Steps to reproduce

Create a cross-targeting project that will emit an error on build. See xTargetError.zip

Build the project with various logger settings.

Expected behavior

Some log setting that provides enough context to identify which configuration of the project is actually emitting the error

Actual behavior

No logger setting provides sufficient data. You need to look at a binlog, or more closely inspect a detailed or normal level log to correlate error to other log statements which might include the TargetFramework value.

Environment data

msbuild /version output: Microsoft (R) Build Engine version 16.1.67-preview+g13843078ee for .NET Core Copyright (C) Microsoft Corporation. All rights reserved.

16.1.67.33811

OS info:

If applicable, version of the tool that invokes MSBuild (Visual Studio, dotnet CLI, etc): dotnet

Suggested solution

A potential solution for this would be to include global properties in the error spew where the project file is currently emitted.

For example, instead of 

Class1.cs(6,8): error CS1029: #error: 'this is an error, but from which configuration?' [D:\scratch\xTargetError\xTargetError.csproj]

Emit

Class1.cs(6,8): error CS1029: #error: 'this is an error, but from which configuration?' [D:\scratch\xTargetError\xTargetError.csproj : TargetFramework=net46]

You could make this opt-in with a Console Logger Parameter.

/cc @stephentoub @nguerrera

rainersigwald commented 5 years ago

Yeah, I've been afraid to do change the text log output to put a TF in there, because I know people parse the logs (if you're reading this: that is not permission for you to parse the logs. Use the structured binary log if you want to do that!).

Opt-in with a /clp: is probably better than nothing, but it's really not optimal. Maybe we could always opt into it from dotnet build, though, at least for the console logger?

nguerrera commented 5 years ago

Maybe we could always opt into it from dotnet build, though, at least for the console logger?

I'm fine with this.