Azure-pipelines-tasks: dotnet build doesn't capture warnings

[dalee-bis]

Environment

• Server - VSTS or TFS on-premises?
  VSTS

• Agent - Hosted or Private:
  Private

Issue Description

We have a .NET Core task which is running a build command. The build is showing warnings in Visual Studio when built locally and also in the logs when being built by VSTS. These are not captured by VSTS and so are not displayed in the build UI.

2018-07-11T14:03:44.2237927Z C:\Program Files\dotnet\sdk\2.1.301\Microsoft.Common.CurrentVersion.targets(2106,5): warning MSB3277: Found conflicts between different versions of "Microsoft.AspNetCore.Hosting" that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [D:\VSTS Agent\_work\23\s\YorkshireWater.LeakageAPI\YorkshireWater.LeakageAPI.Tests\YorkshireWater.LeakageAPI.Tests.csproj]

I believe this is because the command is not using the ##[warning] syntax used by the equivalent Visual Studio build tasks (see example below). Since this is a task for the dotnet command, it should be able to capture the warning messages which it uses.

2018-07-17T08:53:19.6614622Z ##[warning]CSC(0,0): Warning CS8032: An instance of analyzer Microsoft.EntityFrameworkCore.RawSqlStringInjectionDiagnosticAnalyzer cannot be created from C:\Users\svcbuildservervsts\.nuget\packages\microsoft.entityframeworkcore.analyzers\2.1.1\analyzers\dotnet\cs\Microsoft.EntityFrameworkCore.Analyzers.dll : Could not load file or assembly 'Microsoft.CodeAnalysis, Version=2.8.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified..

[SWarnberg]

Yes, it's a big problem for us too. We have a zero-warning policy on checked in code and we need to visualize that on VSTS, just as you could with old VS builds.

[jacqueskang]

We have the same issue, anyone found a walk-around please?

[joko0525]

Yes, it's a big problem for us too. We have a zero-warning policy on checked in code and we need to visualize that on VSTS

Same for our builds, this prevents the Build Quality Checks - Warning Policy VSTS task from working properly

[azooinmyluggage]

We will pick this up as an enhancement to the task in the next sprint planning. Thanks for the feedback!!
Atul

[massigrillo]

the easiest workaround to temporary fix the issue I found out is to use MSBuild task MSBuild@1 instead of of dotnet task DotNetCoreCLI@2 to build an ASP.Net Core solution. So the step would be

- task: MSBuild@1 displayName: Build inputs: configuration : $(buildConfiguration)

instead of

- task: DotNetCoreCLI@2 displayName: Build inputs: command: build configuration : $(buildConfiguration)

So the warnings will be visible in Build Pipeline

[davidschof]

You can also work around this by using the "Warning Filters" regular expression.
e.g.
/\s(\d+)\s+warning/i

[PeterRockstars]

You can also work around this by using the "Warning Filters" regular expression.
e.g.
/\s(\d+)\s+warning/i

This also matches "0 Warning(s)". I think this should do the trick:

/\s([1-9]\d*\.?[0]*)\s+Warning\(s\)|\s([1-9]\d*\.?[0]*)\s+Error\(s\)/

[dotwhat]

I created a (ugly) workaround which can be used to show the build warnings in the Log and Summary tab in Azure Devops. I only tested this azure-pipelines.yml for .NET Core 2.2.102. But feel free to try it out: https://github.com/melisco/azure-devops-dotnet-warnings

[johncrim]

This is still an issue in Azure DevOps over a year later (no errors or warnings reported in the Azure DevOps build). IMO there really needs to be a custom msbuild logger used in "dotnet build" which reports errors in the required format.

[InKahootz]

In a similar note, a forward logger would be nice because using just "dotnet build" along with the GitVersionTask package reference doesn't update the build number since there is no logging. Running the same project with MSBuild task work because of the logging output to the console.

[johncrim]

Note also that many of these workarounds don't work on Linux - as far as I recall, the msbuild task doesn't work correctly on Linux (eg Ubuntu 16.04), b/c the msbuild version resolution is different, and invoking it is different. This is part of the reason why we need an MSBuild logger that writes pipelines output out of the box.

Also, a design suggestion: I think it would be super useful to have a separate nuget package for a dotnet core compatible Azure pipelines msbuild logger. There are a lot of other situations where it could be used (eg when running a cake build in pipelines, and cake calls dotnet build, so would have to pass in the right arguments to use the pipelines logger).

I've thought about writing and sharing my own, but this seems like something Microsoft would/should own... And of course they already have one (referenced from the msbuild task), but it's not shared in source code form or on nuget.

[NenoLoje]

@bishal-pdMSFT Any updates on this one?

[JamesFaix]

I'm running into this as well, trying to build using DotNetCoreCLI@2 on Ubuntu. This seems like a significant bug. Reporting 0 warnings when there are > 0 warnings means bugs can sneak into my code. Going to try that massive powershell blob linked above. 😢

[bishal-pdMSFT]

Thanks for feedback folks. We will plan to start this work in 2-3 weeks time.

[Blackbaud-TommyVernieri]

It looks like this behavior was recently addressed with the release of #12358 in version 2.166.1 of the .NET Core Azure DevOps build task. That task now additionally logs warnings in a line with a ##[warning] prefix. This caught us by surprise because several of our builds have warnings that had gone undetected. After v2.166.1 of the DotNetCoreCLIV2 task was released to our Azure DevOps pipelines, our Check build warnings task (Build Quality Checks) started failing for those builds.

[johncrim]

In case it's useful to anyone who is _not_ using the DotNetCoreCLI@2 task, but is using another way to run dotnet builds and wants build warnings to propagate to their Azure Pipelines build, you can download and unzip the msbuild logger (from https://vstsagenttools.blob.core.windows.net/tools/msbuildlogger/3/msbuildlogger.zip), and add it to your build as a build argument.
(I really wish there was a nuget package for this build logger, but no luck so far)

For example, I am using the following to return an msbuild argument that is used when running in Azure Pipelines:

```c#
///

/// When running on an Azure Pipelines build agent, downloads (if necessary) an Azure build logger, and returns an msbuild argument
/// referencing the build logger.
///

/// An msbuild argument referencing the Azure build logger, when running on a build agent. When not running on a build agent, null is returned.
private async Task CreateBuildAgentMsBuildLoggerArgument()
{
const string buildLoggerPackageUrl = "https://vstsagenttools.blob.core.windows.net/tools/msbuildlogger/3/msbuildlogger.zip";
const string buildLoggerFileName = "Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll";

        // Detect if we're running on a build agent
        var workFolderEnvVar = Environment.GetEnvironmentVariable("AGENT_WORKFOLDER");
        if (string.IsNullOrWhiteSpace(workFolderEnvVar))
        {
            return null;
        }
        var workFolder = new DirectoryInfo(workFolderEnvVar);
        if (! workFolder.Exists)
        {
            return null;
        }

        // Check if build logger assembly has been downloaded
        var buildLoggerFolder = workFolder.Subdir("dotnet-build-logger");
        var buildLoggerDll = new FileInfo(Path.Join(buildLoggerFolder.FullName, buildLoggerFileName));
        if (! buildLoggerDll.Exists)
        {   // Download build logger
            buildLoggerFolder.Create();
            using (var http = new HttpClient())
            {
                var response = await http.GetAsync(new Uri(buildLoggerPackageUrl));
                if (! response.IsSuccessStatusCode)
                {
                    return null;
                }
                await using var responseStream = await response.Content.ReadAsStreamAsync();
                using var archive = new ZipArchive(responseStream);
                foreach (var entry in archive.Entries)
                {
                    var entryFile = Path.GetFullPath(Path.Combine(buildLoggerFolder.FullName, entry.FullName));
                    entry.ExtractToFile(entryFile);
                }
            }

            buildLoggerDll.Refresh();
        }

        return $"-dl:CentralLogger,\"{buildLoggerDll.FullName}\"*ForwardingLogger,\"{buildLoggerDll.FullName}\"";
    }

```

[rosieks]

I wonder if you could also support it out of the .NET Core azure devops task (by providing some nuget package). Some people call dotnet build from powershell or docker file. It would be nice to have nice experience while using this tools too

[haefele]

I have a build script based on bullseye that manually calls into MSBuild.
That allows us to trigger builds manually, independent of Azure DevOps.

Having this logger available would be extremely useful for us tho, so our PR build validation errors show up properly in Azure Pipelines.

[bishal-pdMSFT]

I did not realize that this issue was still open. As @Blackbaud-TommyVernieri commented above the fix is already done via PR https://github.com/microsoft/azure-pipelines-tasks/pull/12358/files

Regarding the ask for a nuget package so that it can be used outside of ADO, I think this repo is not the right target for such ask as it only tracks task issues. May be a better place is to start with .Net Core team on what they think about this.

Hence I am closing this issue.