The 'createdump' tool doesn't currently work in the app sandbox (i.e. when publishing to the App Mac Store).
Ref: dotnet/macios#16189
Making it work as a standalone executable has numerous challenges:
createdump has to be signed with a bundle identifier. It doesn't seem like the same bundle identifier as the main app can be used, although I wasn't able to confirm this (in any case it sounds like a bad idea to re-use the bundle identifier).createdump requires a few custom entitlements: https://github.com/dotnet/runtime/blob/main/eng/pipelines/common/createdump-entitlements.plistcreatedump would also need the sandbox entitlement to publish to the App Store (com.apple.security.app-sandbox).- I'm not entirely sure whether a custom provisioning profile is required. If so,
createdump would have to be put inside an app-like directory structure: https://developer.apple.com/documentation/Xcode/signing-a-daemon-with-a-restricted-entitlement. This is inconvenient, because CoreCLR expects createdump next to one of its dylibs. Maybe this can be worked around with a symlink?
- It seems that since a bundle identifier is required, an Info.plist must be embedded inside the executable, which is done when the executable is linked (by passing
-sectcreate __TEXT __info_plist path/to/Info.plist to ld)... but we get the executable already linked from the runtime pack.
Also interesting: https://developer.apple.com/documentation/xcode/embedding-a-helper-tool-in-a-sandboxed-app
An alternative approach seems to be to embed the createdump functionality as a static library, and then potentially fork before generating the dump. This is apparently what .NET does for single-file executables.
Ref: #84864
Ref: #89203
Ref: https://discord.com/channels/732297728826277939/732297808148824115/1149344656480550912
In any case, we don't even know if there's community interest in supporting createdump functionality in the app sandbox, so if you're interested, please upvote this issue. If we get enough interest, we'll look into it, otherwise we'll eventually close this issue.
The 'createdump' tool doesn't currently work in the app sandbox (i.e. when publishing to the App Mac Store).
Ref: dotnet/macios#16189
Making it work as a standalone executable has numerous challenges:
createdumphas to be signed with a bundle identifier. It doesn't seem like the same bundle identifier as the main app can be used, although I wasn't able to confirm this (in any case it sounds like a bad idea to re-use the bundle identifier).createdumprequires a few custom entitlements: https://github.com/dotnet/runtime/blob/main/eng/pipelines/common/createdump-entitlements.plistcreatedumpwould also need the sandbox entitlement to publish to the App Store (com.apple.security.app-sandbox).createdumpwould have to be put inside an app-like directory structure: https://developer.apple.com/documentation/Xcode/signing-a-daemon-with-a-restricted-entitlement. This is inconvenient, because CoreCLR expectscreatedumpnext to one of its dylibs. Maybe this can be worked around with a symlink?-sectcreate __TEXT __info_plist path/to/Info.plistto ld)... but we get the executable already linked from the runtime pack.Also interesting: https://developer.apple.com/documentation/xcode/embedding-a-helper-tool-in-a-sandboxed-app
An alternative approach seems to be to embed the
createdumpfunctionality as a static library, and then potentially fork before generating the dump. This is apparently what .NET does for single-file executables.Ref: #84864
Ref: #89203
Ref: https://discord.com/channels/732297728826277939/732297808148824115/1149344656480550912
In any case, we don't even know if there's community interest in supporting createdump functionality in the app sandbox, so if you're interested, please upvote this issue. If we get enough interest, we'll look into it, otherwise we'll eventually close this issue.