question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

NativeAOT StripSymbols should allow options for what to do with the symbol file

See original GitHub issue

In trying to make a minimally sized NativeAOT app in a Linux Docker container, the first thing a developer needs to do is set StripSymbols=true. The symbols in the app can bloat the app size by 2-3x.

However, the developer also needs to move the symbols out of their publish directory in order to actually save the size in the Docker image.

Typically, Dockerfiles will publish the app to a specific directory (using -o), and then copy that whole directory into the final container. Here’s an example from https://docs.docker.com/samples/dotnetcore/:

# syntax=docker/dockerfile:1
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build-env
WORKDIR /app
    
# Copy csproj and restore as distinct layers
COPY *.csproj ./
RUN dotnet restore
    
# Copy everything else and build
COPY ../engine/examples ./
RUN dotnet publish -c Release -o out
    
# Build runtime image
FROM mcr.microsoft.com/dotnet/aspnet:6.0
WORKDIR /app
COPY --from=build-env /app/out .
ENTRYPOINT ["dotnet", "aspnetapp.dll"]

Following this same pattern with PublishAot=true will still keep the .dbg file in the app, bloating the image.

We should add some options for what to do with the resulting “stripped” symbol file. Useful options I can think of:

  1. Don’t publish the symbol file in the output folder. (It will still be in the obj folder)
  2. Specify a separate folder to publish the symbol file to

This way developers can simply set this setting in their .csproj (or Directory.Build.props), and they won’t have to write work-around code like this in their Dockerfile:

# remove the symbols so they aren't part of the published app
RUN rm -rf /app/publish/*.dbg

cc @MichalStrehovsky

Issue Analytics

  • State:closed
  • Created a year ago
  • Reactions:1
  • Comments:6 (5 by maintainers)

github_iconTop GitHub Comments

1reaction
MichalStrehovskycommented, Jul 13, 2023

Aaaand looking at the actual sources, looks like there already is such property: CopyOutputSymbolsToPublishDirectory. We just need to respect it for PublishAot. PR out shortly…

0reactions
MichalStrehovskycommented, Jul 13, 2023

There should ideally be a PublishSymbols property that controls whether debug symbols end up part of the publish output.

Without Native AOT in the picture, when you do build, the debug symbols get generated to the obj directory. When you do publish, the publishing process will then go and also copy them to your publish output.

With Native AOT, the process is similar (except that we do everything as part of publish): the output is generated under bin\...\native (along with the PDB/DBG), and then we copy this PDB to the publish output (bin\...\publish, typically).

It feels like what we want is an option to not make the PDB/DBG part of publish.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Breaking change: StripSymbols defaults to true - .NET
Learn about the breaking change in deployment where the default value for 'StripSymbols' is now 'true' for 'PublishAOT'.
Read more >
Untitled
Debugging symbol WebThe "-g -O0" options you provided should indeed let the debugger know all the symbols it needs from the executable.
Read more >
Prevent Visual Studio from trying to load symbols for a ...
10 Answers. You can't do this in a very fine grained fashion but you can disable automatic symbol loading and then manually choose...
Read more >
.NET functions with native AOT compilation - AWS Lambda
Learn how to create and deploy Lambda functions that use .NET 7 with native AOT compilation, which can reduce cold start times.
Read more >
Microsoft Intros Native AOT for ASP.NET Core
Microsoft Native AOT deployment guidance explains that native AOT support lets developers create a self-contained app, AOT-compiled to native ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found