Bug 18842 - Debug build w/o the settings change
Summary: Debug build w/o the settings change
Alias: None
Product: iOS
Classification: Xamarin
Component: Tools ()
Version: 7.2.1
Hardware: PC Mac OS
: Normal normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2014-04-07 15:34 UTC by Todd Berman
Modified: 2014-05-06 12:24 UTC (History)
5 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report for Bug 18842 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:

Description Todd Berman 2014-04-07 15:34:31 UTC
It would be great to be able to generate a debug build of a Xamarin.iOS app that doesn't cause the settings plist change. We want to do an alpha/beta build that has debug turned on, but because it has the settings screen that has all kinds of nerdy stuff in it, we can't.

I know that we could hand edit the plist and then resign, but it would be great if that was something we could enable/disable as part of our AdHoc build configuration.
Comment 1 Jeffrey Stedfast 2014-04-07 16:01:14 UTC
There are 2 debug checkboxes (I know, it's kinda confusing). One is in the Compiler preferences (which is what I think you want) which includes debugging symbols and such and one in the iOS Bundle preferences, which is what adds the Settings.bundle preferences (which is what you don't want) and allows the IDE to remotely connect and debug the app.

If you enable the first but disable the second, I *think* that'll get you what you want.
Comment 2 Todd Berman 2014-04-07 16:07:31 UTC
Will try and report back.
Comment 3 Todd Berman 2014-04-10 18:16:51 UTC
Nope, no line numbers.
Comment 4 Jeffrey Stedfast 2014-04-10 18:59:55 UTC
ok, I will have to dig into this...
Comment 5 Jeffrey Stedfast 2014-04-29 16:41:01 UTC
Ok, I think the problem is that mtouch assumes that if it doesn't get the -debug switch, it must strip out the debugging symbols?

Sebastien: is this correct?

What Todd has in his .csproj file is:


The Debug property is what controls the -debug switch passed to mcs but the MtouchDebug property is what controls the -debug switch that is passed to mtouch (as well as whether or not to merge the debug configuration plist into the Settings.bundle)

Todd doesn't want the Settings.bundle merging, but *does* want the debugging symbols in his build.

Any suggestions?
Comment 6 Rolf Bjarne Kvinge [MSFT] 2014-04-30 07:54:35 UTC
Todd, exactly which features do you want to keep with "build that has debug turned on" (as opposed to a release build)? Do you want to be able to use a debugger to debug the application, or is there anything else you need?
Comment 7 Todd Berman 2014-04-30 10:07:06 UTC
I want stacks with line numbers and filenames in our ad-hoc builds so crash reporting is more useful, but I don't want that settings bundle nonsense (since we are distributing these builds to beta users)
Comment 8 Rolf Bjarne Kvinge [MSFT] 2014-05-05 10:07:35 UTC
You should get file name + line number information as long as "Debug information" is set to "Full" on the Build/Compiler option page, otherwise it's a bug.
Comment 9 Todd Berman 2014-05-05 11:32:29 UTC
Rolf, is your goal here to provide maximum frustration?

This bug report comes out of corresponding with you on support case 67230. You told me that this doesn't exist, and isn't on the roadmap and to file a bug.

Anyway, there is a bug, because my Ad-Hoc builds have that Debug setting set to 'Full' and I get no filename and line numbers in my stack.
Comment 10 Rolf Bjarne Kvinge [MSFT] 2014-05-06 05:09:24 UTC
@Todd, I'm sorry I was unclear (definitively not trying to be frustrating :) I was just trying to help - from what I understand you don't necessarily want a "debug build without the debug settings", you want a "build without the debug settings that will produce file and line number information in crash reports."

We support the second case for all builds as long as LLVM is disabled and the managed (C#/F#) compiler is producing debug info (mdb/pdb), so that customers can get as much information as possible from release builds that crashes (there is no performance or size penalty for the app, since the debug information required to translate method addresses to source code location is not stored in the app itself, but in the .dSYM directory).

I just tried the test app here: https://github.com/rolfbjarne/TestApp - and Release builds are getting file / line number information (I tapped on one of the buttons and fetched the crash report in Xcode). Could you provide a test case where it doesn't work for you?
Comment 11 Todd Berman 2014-05-06 10:40:07 UTC
So we are using Raygun to capture exceptions, and when built in Debug mode, it gets filenames/line numbers in stack traces that it captures, however w/ Ad-Hoc (with Debug set to full) it doesn't.
Comment 12 Rolf Bjarne Kvinge [MSFT] 2014-05-06 12:24:05 UTC
OK, I thought you were talking about the crash reports created by iOS when the app crashes.

Raygun requires the mbd files to be present in the app in order to symbolicate stack traces, and Xamarin.iOS will not put mdb files in the app unless -debug is passed to mtouch (see comment #5), which is controlled by the MtouchDebug flag in the csproj, which also controls if Xamarin Studio will add the debug settings to the app.

So back to square one, Xamarin Studio uses the same flag to make two different decisions.

However I believe it's possible to accomplish what you need without any changes to either Xamarin Studio nor Xamarin.iOS: by adding a post-build step to the configuration that removes the Settings.bundle (or copies over the correct version), and then resigns the app. Resigning the app should be fairly simple (the exact command to use is printed to Xamarin Studio's build output at the end of the build)