We have been facing issues with DSYM file and we asked on Xamarin Forums but without a solution
Solution we have found:
We have realized that the "Archive" option in XS messes up the DSYM for some reason. If you are using "Archive" to create your final ipa to upload to TestFlight, do this:
1) Select the Build Type (i.e AppStore/Ad-Hoc/etc)
2) Do a build (this will create IPA + DSYM files in the bin/BuildType directory
3) Make a copy of the DSYM file. This file is correct and you can upload to Insights.
4) Use the "Archive" option to create the final IPA file to upload to TestFlight. Don't use the DSYM file created after using the "Archive" option because its incorrect (you can notice the difference in the size clearly)
Xamarin Studio: Version 6.0 (build 5156)
Apple Developer Tools: Xcode 7.3.1 (10188.1) Build 7D1014
Xamarin.iOS: Version: 184.108.40.2068
Is this only happening on the preview channels or do you see the same thing on Stable?
Could you please provide the following:
1. Your full version info:
Xamarin Studio in OS X
Xamarin Studio -> About Xamarin Studio -> Show Details -> Copy Information [button]
Xamarin for Mac logs:
You can select the "Go -> Go to Folder" menu item in Finder, and then copy and paste the path into the dialog.
This folder can also be opened via "Help -> Open Log Directory".
3. A sample that exhibits the problem.
Moving off the SR1 milestone as we have not received the requested information.
We have not received the requested information. If you are still
experiencing this issue please provide all the requested information
and re-open the bug report. Thanks!
I'm currently having this issue with Xamarin 6.1.1 (build 15). Doing a Release|iPhone build creates the correct dSYM file (about 100 MB). Then when I do an Archive for Publishing build, it creates a much smaller dSYM without the symbols for my app (17 KB). I realize that the bug was closed but I'm wondering if this ever came up anywhere else and if a resolution was found. Web searches aren't turning up anything.
I think I know what might be happening.
When you do your original build, as you mentioned the dSYMs are correct (@ around ~100MB). When you Archive, the Archive MSBuild target depends on the Build target and so a new build runs. In an ideal scenario, each build step would be a no-op. Unfortunately, somehow the _GenerateDebugSymbols target is running again, but because the mtouch task did not generate a new native executable, it remains stripped from the previous build and so dsymutil gets run on a stripped binary which produces a worthless dSYMs.
I suspect the solution is to fix the SymbolStrip task to restore the LastWriteTime timestamp of the native executable -or- to update the timestamp on the dSYMs Info.plist.
Is there anything that I can provide you with that will help you resolve this?
This only started recently. Maybe a couple of minor releases ago. If this is happening for all users of the latest stable releases, then I don't get why there haven't been more complaints about it. It leads me to believe the issue is configuration or something else different in some environments.
Hmmm, not so sure anymore because the _CodesignAppBundle target already updates the mtime timestamp of the dSYM's Info.plist file which should have had the same effect.
Okay, I haven't had any luck reproducing this locally so I may need you to set your Xamarin Studio -> Preferences -> Projects -> Build -> Log verbosity to "Diagnostic" and then do the following:
1. Build -> Clean All
2. Build -> Build All
3. Copy the Build Output (Errors pad -> Build Output) to a text file
4. Build -> Archive for Publishing
5. Copy the Build Output (Errors pad -> Build Output) to a text file
Then attach the build output files from steps 3 and 5 to this bug report (individually or in a zip file is fine, whichever is more convenient)
(Note: feel free to check the checkbox that says "Make attachment and comment private")
FWIW, as a workaround, try doing:
Build -> Clean All
Build -> Archive for Publishing
Let me know if that fixes things for you (obviously not ideal, but useful as a temporary workaround)
> "Make attachment and comment private"
As a heads up for Jeff, note that in Bugzilla 5.0, that checkbox is not by default available to users.
For Ron, if you would like to post back the information privately, please file a new bug and be sure to pick the "Xamarin Team (Private Bug)" checkbox on  or the "Only Xamarins should see this bug" checkbox on . (Posting a new bug has other bookkeeping advantages too, but no need to worry about those if you are content to leave the requested information public on this existing bug report.) Thanks!
Slight correction, "that checkbox is not by default available to users" should more accurately say "That checkbox appears on the 'Add an attachment' page for users, but it won't work for them: if it's enabled it will cause an error when attempting to submit the attachment."
Thanks guys. I've logged #47803 with the requested info.
*** Bug 47803 has been marked as a duplicate of this bug. ***
Fixed in https://github.com/xamarin/xamarin-macios/pull/1261
For an explanation of what is going wrong, see https://bugzilla.xamarin.com/show_bug.cgi?id=47803#c9
Thanks @jeffstedfast I am able to reproduce this issue with your steps mentioned in trello card using stable builds.
However with master build of X.iOS, I am observing that this issue has been fixed. using build xamarin.ios-10.5.0.156_33e778bd660508586c2bff61649e66999c19def3
Hence, closing this issue by makring it as Verified.
Please read the comment in the link above. People are still facing the issue. I would suggest not closing or marking the issue as verified until the fix is released to a public build.
The fix has already been back-ported to cycle8 (what is currently in stable) and cycle9.
Our policy is that we close bugs when the patches have been accepted into the appropriate branch(es).