Summary

Today it's possible to provide the -bl flag multiple times, but the behavior of the engine is that the last-provided flag wins:

> dotnet build -bl:1.binlog -bl:2.binlog
Restore complete (0.1s)
    info NETSDK1057: You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
  lib2 net10.0 succeeded (0.1s) → D:\Code\scratch\bleh\lib2\bin\Debug\net10.0\lib2.dll
  bleh net10.0 succeeded (0.1s) → bin\Debug\net10.0\bleh.dll

Build succeeded in 0.5s
> ls *.binlog

    Directory: D:\Code\scratch\bleh\lib

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---          10/29/2025 11:14 AM         454756 2.binlog

This is confusing, and in extreme cases can mean that tools that need binlogs and provide them via things like response files can be overridden by a users invocation.

Background and Motivation

The inability to write more than one binlog file means that tools like codeql have a harder time adopting binlog usage for C# code analysis, because they can't control where the binlog is generated.

Proposed Feature

The command-line handling should accept multiple bl flags, resolve them into their distinct binlog filenames, ensure that set is distinct, and then the binary logger should be able to write binary logs to all of those specified files.

This file writing could be done in two ways (at least)

• multiple independent writers, each writing to a separate file
• one writer, writing the binlog file to a temp location and then atomically copying that file to the various destinations at build-finish

We should use the second option for consistency.

Alternative Designs

No response