Cannot make trimmed app with debugging symbols

[dmorrison42]

Unfortunately, I am unsure if this is a feature request, bug report, or my failure to properly read the documentation, but I am unable to make a trimmed single executable with debugging symbols. I have a simple code example here : https://github.com/dmorrison42/CrashTestDummy

The following line will create a single executable that will print a line number of an exception, but is fairly large (~67M).

dotnet publish -c release -r win10-x64 -p:PublishSingleFile=true -p:IncludeSymbolsInSingleFile=true -o .

The following line with create a single executable that will print no line number, but is relatively small (~25M).

dotnet publish -c release -r win10-x64 -p:PublishSingleFile=true -p:IncludeSymbolsInSingleFile=true -p:PublishTrimmed=true -o .

Update: As of dotnet core 3.1.100. The workaround provided by @sbomer works.

Just add the following to the csproj:

  <ItemGroup>
    <TrimmerRootAssembly Include="System.Diagnostics.StackTrace" />
  </ItemGroup>
  <PropertyGroup>
    <_ExtraTrimmerArgs>--keep-facades true</_ExtraTrimmerArgs>
  </PropertyGroup>

The sample project has been updated appropriately.

[swaroop-sridhar]

@dmorrison42 can you try to isolate whether you see the issue due to single-file or trimming?

For example, what happens with the following builds?
dotnet publish -c release -r win7-x64 -p:PublishTrimmed=true
dotnet publish -c release -r win7-x64 -p:PublishTrimmed=true -p:PublishSingleFile=true
dotnet publish -c release -r win10-x64 -p:PublishTrimmed=true -p:PublishSingleFile=true

Thanks.

CC: @sbomer @tlakollo @vitek-karas

[dmorrison42]

@swaroop-sridhar thank you for looking into this for me!

First, everything appears to work the same on Windows 10 so we'll just assume we're running Windows 10 (ignoring the win7-x64 from the original issue).

Second, neither any of the commands you listed printed line numbers, nor any of their -r win10-x64 equivalents.

I think what this means is that the trimming is what is causing the issue which matches with my original experiments.

[sbomer]

This happens because the linker is removing the diagnostics assembly used to resolve symbols. To work around this, you can add the following to your project:

  <ItemGroup>
    <TrimmerRootAssembly Include="System.Diagnostics.StackTrace" />
  </ItemGroup>

This will add System.Diagnostics.StackTrace and its trimmed dependencies (System.Diagnostics.Tools, System.Collections, System.Collections.Immutable, System.IO.Compression, System.IO.FileSystem, System.IO.MemoryMappedFiles, System.Linq, System.Reflection.Metadata, and System.Runtime) to the output, increasing the size by ~1.3MB for your sample app.

The linker generally understands the reflection pattern used to get a type from this assembly. However, because the assembly isn't referenced, it is never loaded into the set of assemblies in the linker context, so the pattern isn't resolved.

@vitek-karas this might be one of the special cases worth teaching the linker about. I think it's valuable to have an option that would keep the stacktrace assembly. Maybe we should make this the default at least in Debug builds.

[vitek-karas]

Just curious - these assemblies are only needed when calling things like Exception.ToString() - why would the linker not pick it up? Or is it only under the debugger?

I think it should be the other way round

• By default linker should not break the app in any way - so it should include all this code
• Given the large size (1.3 MB) and the rather specific use case for it, it would be really nice to have an option to exclude this code.

The Debug/Release is probably not a good indicator though - most apps will probably never run publish on Debug builds, only on Release builds. It should also be possible to get full call stacks on release builds.

[dmorrison42]

@sbomer thanks, this looks like the right track, but I haven't been able to get it to work yet.

I added a commit doing what I thought you suggested, but either I messed something up, or it doesn't quite fix it. https://github.com/dmorrison42/CrashTestDummy/tree/stacktrace_workaround

I played around with it a bit beyond that last night, but still nothing. (Also I updated the OS in the original issue for better search-ability).

[sbomer]

@dmorrison42 you are right, there is more to it (I was using a different linker build earlier). It looks like there was a bug in the linker that caused problems even with the workaround. It was fixed by dotnet/linker@b1f6390#diff-f34bf215167cc5e716cfa3986a630341. As a workaround, you can disable the optimization that removes facades. This will re-introduce a large number of files in the output, but fortunately they are pretty small (I see a total size of 28.9MB with both workarounds):

<PropertyGroup>
  <_ExtraTrimmerArgs>--keep-facades true</_ExtraTrimmerArgs>
</PropertyGroup>

@vitek-karas seems to me that:

• The app doesn't have any direct references that pull in the StackTrace assembly
• The linker loads the reference closure into the LinkContext
• The linker sees this reflection pattern, but doesn't resolve the assembly because it's not part of the context.

We could change this behavior so that the reflection detection is able to resolve assemblies that are part of the input set but not the reference closure. If we do that, the default becomes to keep this code. I agree that it would be nice to have an option to exclude it.

[dmorrison42]

Thanks @sbomer that worked!

It sounds like you want to fix this in the linker so I'll leave the issue open so it can be fixed correctly.

[vitek-karas]

This is in spirit very similar to dotnet/linker#843. Basically linker has no way to add an assembly to the closure during later steps (including MarkStep). There are several ways we can go about changing that, but I fear none is actually "Easy".
A workaround might be to add PreserveDependencyAttribute on the method - that has the ability to pull more assemblies into the closure. Given that there's no good way to cut this code conditionally (it's driven by parameter values, so there's no way to tell statically if it's going to be needed), for correctness we will need to keep it always.

[vitek-karas]

I verified that adding the attribute correctly brings in the necessary dependencies (it also makes the app larger obviously - in full trim mode by 200 KB as it bring in some of System.IO and System.Reflection.Metadata)

[github-actions]

Due to lack of recent activity, this issue has been labeled as 'Stale'. It will be closed if no further activity occurs within 30 more days. Any new comment will remove the label.