-p:DebugSymbols=false does not disable generation of .pdb files

[jkotas]

Describe the bug

https://learn.microsoft.com/en-us/visualstudio/msbuild/common-msbuild-project-properties?view=vs-2022 states:

Setting -p:DebugSymbols=false on the command line disables generation of program database (.pdb) symbol files.

This does not match .NET 8 SDK behavior.

-p:DebugType=None is the actual property that can be used to disable the .pdb symbol generation.

DebugSymbols property should be either documented as obsolete and no longer supported with DebugType as recommended replacement; or the behavior DebugSymbols property should be fixed to match the documentation.

To Reproduce

dotnet new console
dotnet build -p:DebugSymbols=false
dir /s *.pdb

Actual result: .pdb file is generated
Expected result: No .pdb file is generated

Further technical details

.NET SDK 8.0.205

[Forgind]

MSBuild owns DebugSymbols; would you mind taking a first look?

[rainersigwald]

The compiler is passed both

EmitDebugInformation = False
DebugType = portable

and produces this part of the command line

/debug- /debug:portable

The csc help doesn't specify a precedence here but manually swapping those changes the behavior to

❯ &"C:\Program Files\dotnet\dotnet.exe" exec "C:\Program Files\dotnet\sdk\8.0.300\Roslyn\bincore\csc.dll" /noconfig `@foo.rsp
Microsoft (R) Visual C# Compiler version 4.10.0-3.24216.12 (3af0081a)
Copyright (C) Microsoft Corporation. All rights reserved.

error CS2045: /embed switch is only supported when emitting a PDB.

@jaredpar would you say we should treat this as a Csc task bug (allows passing multiple contradictory params without warning), an SDK bug (doesn't respect DebugSymbols when setting other properties, resulting in the contradictory params), or a doc bug?

[jaredpar]

allows passing multiple contradictory params without warning

The compilers have long allowed for contradictory params to be provided. There are ample tests in the native and Roslyn compiler to ensure we handle contradictory parameters correctly. Not my preferred design but it's very much baked into how the compiler operates.

The csc help doesn't specify a precedence here but manually swapping those changes the behavior to

Unless stated otherwise the last switch wins.

[rainersigwald]

At the compiler CLI layer I think that's fine and wouldn't want to change at this point, but at the task layer there's no user control over order so they're at the mercy of what the task chooses.

(I lean toward "this is an SDK bug" personally)

[jaredpar]

Yeah if we want universal behavior for all the languages then feels like something that should be handled at the SDK layer. Basically normalize out the properties so that all the compilers don't have to individually do this work.

[Forgind]

Ah, I'd assumed we were just passing information to MSBuild, and it was getting mangled either there or at the compiler. It sounds like the problem is that we look for a particular property and pass a default value if it isn't present but won't notice an alternate way of expressing a similar concept. Does that sound right? If so, I think I'd agree that this is probably best resolved in the SDK layer by not expressing that.

Looking around, this seems by far the most likely culprit:

sdk/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.props

Line 97 in 1c7a2e4

<DebugType Condition=" '$(DebugType)' == '' ">portable</DebugType>

I can change that to set DebugType to None if DebugSymbols is set to false if that sounds reasonable to you.