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.
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.
Will try and report back.
Nope, no line numbers.
ok, I will have to dig into this...
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.
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?
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)
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.
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.
@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?
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.
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)