.NET: Not generating .dSYMs #14067

rolfbjarne · 2022-02-04T07:36:24Z

It seems that net6.0-ios builds do not generate dSYM symbols. What is the recommended approach for generating them?

I am currently using the following workaround:

<Target Name="PrepareGenerateDSymFiles"
        AfterTargets="_PrepareDebugSymbolGeneration"
        BeforeTargets="_GenerateDebugSymbols">
    <ItemGroup>
        <_AppExtensionDebugSymbolProperties>
            <NoDSymUtil>true</NoDSymUtil>
            <NoSymbolStrip>true</NoSymbolStrip>
        </_AppExtensionDebugSymbolProperties>
    </ItemGroup>
</Target>

<Target Name="GenerateDSymFiles"
        AfterTargets="_CopyAppExtensionsToBundle"
        DependsOnTargets="_GetNativeExecutableName;
                          _PrepareDebugSymbolGeneration;
                          PrepareGenerateDSymFiles;
                          _GenerateDebugSymbols">
</Target>

The text was updated successfully, but these errors were encountered:

…ripping. Fixes dotnet#14067. ---- This turned out somewhat non-straight-forward for universal builds, because debug symbols are created for the universal app bundle, not for each rid-specific version of the app bundle. So I had to add logic to create the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then collect them and merge those lists for the universal app bundle. The existing SymbolStrip call we did right after linking the native executable was removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols target does). Also add tests. --- Fixes dotnet#14067.

…code signing. Fixes dotnet#14067. Change code signing to only sign when we're building the outermost app bundle (previously we'd sign each app extension or watch app before copying them into the app bundle). This makes it easier to handle code signing fpr .NET universal apps, when we merge RID-specific bundles and can only codesign at the very end anyway. This also means that we have to change dSYM generation and native stripping accordingly: they're done immediately before code signing now, in a newly minted post processing target. Challenges: * Both calling 'strip' and 'codesign' on an executable modifies that executable, which means that we must make sure to not call 'dsymutil' on the same binary at a later point unless it's been rebuilt. * Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip' and/or 'codesign' on an executable. # Changes * macOS: we'll always sign frameworks (like we've always signed dylibs). # TODO Run submission tests. ---- This turned out somewhat non-straight-forward for universal builds, because debug symbols are created for the universal app bundle, not for each rid-specific version of the app bundle. So I had to add logic to create the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then collect them and merge those lists for the universal app bundle. The existing SymbolStrip call we did right after linking the native executable was removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols target does). Also add tests. --- Fixes dotnet#14067.

…code signing. Fixes dotnet#14067. Change code signing to only sign when we're building the outermost app bundle (previously we'd sign each app extension or watch app before copying them into the app bundle). This makes it easier to handle code signing fpr .NET universal apps, when we merge RID-specific bundles and can only codesign at the very end anyway. This also means that we have to change dSYM generation and native stripping accordingly: they're done immediately before code signing now, in a newly minted post processing target. Challenges: * Both calling 'strip' and 'codesign' on an executable modifies that executable, which means that we must make sure to not call 'dsymutil' on the same binary at a later point unless it's been rebuilt. * Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip' and/or 'codesign' on an executable. * macOS: we'll always sign frameworks (like we've always signed dylibs). Run submission tests. ---- This turned out somewhat non-straight-forward for universal builds, because debug symbols are created for the universal app bundle, not for each rid-specific version of the app bundle. So I had to add logic to create the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then collect them and merge those lists for the universal app bundle. The existing SymbolStrip call we did right after linking the native executable was removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols target does). Also add tests. --- Fixes dotnet#14067.

dotnet#14067. Change dSYM generation and native stripping to occur immediately before code signing, in a newly minted post processing target. Challenges: * Both calling 'strip' and 'codesign' on an executable modifies that executable, which means that we must make sure to not call 'dsymutil' on the same binary at a later point unless it's been rebuilt. * Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip' and/or 'codesign' on an executable. * Just like for code signing, we must store the libraries (either static or dynamic) we post process in extension/watch/rid-specific projects, so that these libraries can be loaded in containing projects and processed there. * In universal .NET builds, debug symbols are created for the universal app bundle, not for each rid-specific version of the app bundle. So I had to add logic to create the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then collect them and merge those lists for the universal app bundle. The existing SymbolStrip call we did right after linking the native executable has been removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols target does). Also add tests. Fixes dotnet#14067.

#14067. (#14335) Change dSYM generation and native stripping to occur immediately before code signing, in a newly minted post processing target. Challenges: * Both calling 'strip' and 'codesign' on an executable modifies that executable, which means that we must make sure to not call 'dsymutil' on the same binary at a later point unless it's been rebuilt. * Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip' and/or 'codesign' on an executable. * Just like for code signing, we must store the list libraries (either static or dynamic) we post process in extension/watch/rid-specific projects, so that these libraries can be loaded in containing projects and processed there. * In universal .NET builds, debug symbols are created for the universal app bundle, not for each rid-specific version of the app bundle. So I had to add logic to create the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then collect them and merge those lists for the universal app bundle. The existing SymbolStrip call we did right after linking the native executable has been removed, because we have to do that after creating the dSYM. Also add tests. Fixes #14067.

rolfbjarne added dotnet An issue or pull request related to .NET (6) dotnet-pri0 .NET 6: required for stable release labels Feb 4, 2022

rolfbjarne added this to the .NET 6 milestone Feb 4, 2022

rolfbjarne added the bug If an issue is a bug or a pull request a bug fix label Feb 4, 2022

rolfbjarne mentioned this issue Feb 4, 2022

System.IO.IOException: Sharing violation on path executing dotnet publish when referencing package containing culture specific resource assemblies in subdirectories #13838

Closed

rolfbjarne self-assigned this Feb 11, 2022

rolfbjarne mentioned this issue Mar 8, 2022

[msbuild/dotnet] Rework how we handle app bundle post processing. Fixes #14067. #14335

Merged

rolfbjarne closed this as completed in #14335 Mar 24, 2022

ghost locked as resolved and limited conversation to collaborators Apr 26, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

.NET: Not generating .dSYMs #14067

.NET: Not generating .dSYMs #14067

rolfbjarne commented Feb 4, 2022

.NET: Not generating .dSYMs #14067

.NET: Not generating .dSYMs #14067

Comments

rolfbjarne commented Feb 4, 2022