Sdk: Is it possible not to generate pdb file?

[parjong]

It seems that dotnet build always generates pdb file (even for Release configuration). Is it possible not to generate pdb file?

Steps to reproduce

$ mkdir dotnet_sample
$ cd dotnet_sample
$ dotnet new
$ dotnet restore
$ dotnet publish -c Debug
...
$ dotnet publish -c Release
...
$ ls bin/Debug/netstandard1.5/publish
...
$ ls bin/Release/netstandard1.5/publish
...

Expected behavior

...
$ ls bin/Debug/netstandard1.5/publish/
dotnet_example.deps.json dotnet_example.dll dotnet_example.pdb dotnet_example.runtimeconfig.json
$ ls bin/Release/netstandard1.5/publish/
dotnet_example.deps.json dotnet_example.dll dotnet_example.runtimeconfig.json

Actual behavior

...
$ ls bin/Debug/netstandard1.5/publish/
dotnet_example.deps.json dotnet_example.dll dotnet_example.pdb dotnet_example.runtimeconfig.json
$ ls bin/Release/netstandard1.5/publish/
dotnet_example.deps.json dotnet_example.dll dotnet_example.pdb dotnet_example.runtimeconfig.json

Environment data

$ dotnet --info
.NET Command Line Tools (1.0.0-beta-002181)

Product Information:
Version: 1.0.0-beta-002181
Commit Sha: e4cdc250e9

Runtime Environment:
OS Name: ubuntu
OS Version: 14.04
OS Platform: Linux
RID: ubuntu.14.04-x64

[TheRealPiotrP]

@jaredpar @gregg-miskelly @blackdwarf it would be good to get your thoughts here.

I understand the Release configuration to generate valid and useful PDBs. If these are not desirable for a particular distribution scenario then they can be cleaned out post-publish. What do you think? Have we started dropping PDBs for Release configurations?

[parjong]

@piotrpMSFT

The approach that you mentioned is the first approach that I considered, but I can't use that approach since there is a difference in outcome itself. The following showed the comparision result:
$ ls -al bin/_/netstandard1.5/_.dll
-rwxrw---- 1 parjong parjong 5120 Apr 4 11:37 bin/Debug/netstandard1.5/csharp_benchmark.dll
-rwxrw---- 1 parjong parjong 4608 Apr 4 11:48 bin/Distribute/netstandard1.5/csharp_benchmark.dll
-rwxrw---- 1 parjong parjong 5120 Apr 4 11:37 bin/Release/netstandard1.5/csharp_benchmark.dll

The DLL under 'bin/Distribute/netstandard1.5' is obtained by manually invoking compiler with /debug- option,and the DLLs under 'bin/Debug' and 'bin/Release' are obtained by 'dotnet build -c Debug' and 'dotnet build -c Release', respectively.

Note that the binary size becomes smaller with /debug- option.

I plan to use .NET Core under resource-limited environment, and thus the final outcome should be optimized as much as possible.

PDB is useful for most scenarios, and thus it would be better to have another way to suppress PDB instead of using Release configuration.

I tried to suppress PDB generation via modifying 'project.json', but unfortunately it seems that there is no avaiable option currently.

[gregg-miskelly]

I don't see any problem with adding a compilation option to disable PDB generation. I don't think it should be the default behavior.

[jaredpar]

Enabling this requires a small change to this line:

https://github.com/dotnet/cli/blob/ac4c6702d5d345dc9c397f80290f105fedebe98b/src/dotnet/commands/dotnet-compile-csc/Program.cs#L224

At a glance I should have just coded that as something closer to:

commonArgs.Add($"-debug:{options.DebugType");

Then we could support this via the following option in project.json

debugType: "none"

[livarcocc]

Now, with msbuild, you can do that by simply running

dotnet build /p:DebugType=None

Alternatively,

you can just do the snippet below to your CSProj.

<PropertyGroup>
  <DebugType>None</DebugType>
</PropertyGroup>

You can even condition this to Release only with

<PropertyGroup>
  <DebugType Condition=" '$(Configuration)' == 'Release' ">None</DebugType>
</PropertyGroup>

[emirhosseini]

@livarcocc When running "dotnet publish" it seems to ignore this setting. Does this only work with "dotnet build"? We're only using dotnet restore and then dotnet publish.

[jasatwal]

Try adding the following to your csproj file:

<PropertyGroup>
    <CopyOutputSymbolsToPublishDirectory>false</CopyOutputSymbolsToPublishDirectory>
</PropertyGroup>

Or running the following command:

dotnet publish <PROJECT> /p:CopyOutputSymbolsToPublishDirectory=false

[nzain]

@jasatwal both suggestions did not work for me, when using dotnet publish, pdb files are generated nonetheless. This is on version 2.0.0.

[poulad]

I had the same problem. Adding this to .csproj file(s) fixes it.

<PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
  <DebugType>None</DebugType>
  <DebugSymbols>false</DebugSymbols>
</PropertyGroup>

[maxpavlov]

With .NET Core 3 (Preview 10) specifying /p:CopyOutputSymbolsToPublishDirectory=false effectively works to have no pdb generated in the publish directroy. Case closed :)

[newpost]

With .NET Core 3 (Preview 10) specifying /p:CopyOutputSymbolsToPublishDirectory=false effectively works to have no pdb generated in the publish directroy. Case closed :)

where is url link about it ?

[mk0003]

/p:DebugType=None works for dotnet publish on .NET Core 3.0

[yyjdelete]

Seems CopyOutputSymbolsToPublishDirectory=false is not really work, or already broken for ProjectReference.

The build log show the pdb file for ProjectReference is treated as related file
(AllowedReferenceRelatedFileExtensions?), and added again, only the pdb for main assembly will be removed.

And SkipCopyingSymbolsToOutputDirectory=true or CopyOutputSymbolsToOutputDirectory=false works for me to remove pdbs for ProjectReference(CopyOutputSymbolsToPublishDirectory=false is still needed to remove pdb for the main assembly)

Unlike DebugType=None, the pdb files is still generated in obj folder, and can be loaded if needed.