CopyOutputSymbolsToPublishDirectory is not respected

[MichalStrehovsky]

It used to be the case that CopyOutputSymbolsToPublishDirectory=false would prevent copying PDB/symbols to the publish folder, but it looks like we dropped it in #89358.

Cc @agocke

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

It used to be the case that CopyOutputSymbolsToPublishDirectory=false would prevent copying PDB/symbols to the publish folder, but it looks like we dropped it in #89358.

Cc @agocke

Author:	MichalStrehovsky
Assignees:	-
Labels:	area-NativeAOT-coreclr
Milestone:	-

[richlander]

Could we consider PublishDebugType or PublishSymbols as the convenience version of that. That property is a mouthful and bordering on sausage making.

[jkotas]

The current plan where we simply drop the symbols is not great. It produces containers that are small, but they cannot be run with debugger attached and the crash dumps cannot be analyzed.

One way to solve this issue is to create two containers: Smaller production container without the symbols that is used for production, and layer over the small container that adds the symbols and that can be used to debug the app or analyze crash dumps.

How is this problem typically solved in other languages that produce fully native binaries (C/C++, Rust, golang, ...)?

[MichalStrehovsky]

Could we consider PublishDebugType or PublishSymbols as the convenience version of that. That property is a mouthful and bordering on sausage making.

We didn't invent this name - this has been named like this since forever. The bug here is just that we don't respect the property for PublishAot (it is respected for other kinds of publishes).

If we want to create an alias, it would have to be a separate issue for the SDK repo. I don't know what's our policy on MSBuild aliases. Might be more palatable to expose it as an additional switch to dotnet publish (and e.g. we could add an option to dump the symbols to a different directory as well).

How is this problem typically solved in other languages that produce fully native binaries (C/C++, Rust, golang, ...)?

I tried to search around and asked bing chat as well but came empty handed. E.g. CMake release builds default to not generating any debug info, one needs to choose a RelWithDebInfo configuration to get that. So maybe it's solved by giving a blank stare if someone wants to debug a crash dump.

[richlander]

@jkotas raises a great point. Seems like we should develop a pattern that we like and productize it (and validate it).

The smaller/bigger option would work in some scenarios but not others. For examples, Kubernetes deployments are immutable so you cannot deploy another container to a pod after the fact. The same is likely true for more bespoke services like Azure App Service. For dump debugging, that would work.

In terms of authoring, you could do one of two things, assuming Dockerfile.

• Use two stages and build two different ways, relying on the builds being the same.
• Build the app once to product the big image. docker build a second time, FROM the first image that just harvests the app (not symbols) from the big image and then copies those to the final base image.