Bug 9809 - Linker removes debugger support attributes referenced members
Summary: Linker removes debugger support attributes referenced members
Alias: None
Product: iOS
Classification: Xamarin
Component: Tools ()
Version: 6.0.x
Hardware: PC Mac OS
: --- enhancement
Target Milestone: Untriaged
Assignee: Sebastien Pouliot
Depends on:
Reported: 2013-01-27 04:44 UTC by Marek Safar
Modified: 2013-12-05 18:34 UTC (History)
3 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 on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Marek Safar 2013-01-27 04:44:52 UTC
Linker removes debugger support attributes even if debugging support is enabled in project settings.

Tested only DebuggerDisplayAttribute not all 8 Debugger* attributes
Comment 1 Sebastien Pouliot 2013-01-27 11:26:29 UTC
Pretty sure you not using 5.99.x, which version/branch of MT are you using ?
Comment 2 Marek Safar 2013-01-27 14:14:00 UTC
master from today
Comment 3 Marek Safar 2013-01-27 16:04:32 UTC
Here is the repro

Hover over x, it returns "null" correctly on simulator and missing member on device with enabled debugging

var x = new MonoTouch.AudioToolbox.AudioStreamBasicDescription ();
Comment 4 Sebastien Pouliot 2013-01-28 11:27:12 UTC
There are 9 debug related attributes under System.Diagnostics and the linker _only_ removes them on release builds (not for debug builds). 

I added a new test case to ensure that this works like intended :

Can you attach a full build log (so I can see if mtouch gets the right arguments wrt debugging) in case it's realetd to MD/addin ?

It's possible that something else, beside the attributes but required by the debugger, gets linked out. I'll check that...
Comment 5 Marek Safar 2013-01-28 12:06:04 UTC
Did you try my test ?

DebuggerDisplayAttribute can have reference to linked out method/property/types/etc. I am guessing that's the issue. Other attributes have different rules, so will have to check them separately.
Comment 6 Sebastien Pouliot 2013-01-31 14:50:57 UTC
AudioStreamBasicDescription is decorated with [DebuggerDisplay ("{FormatName}")]

The debugger will shows {Unknown member 'FormatName'} if FormatName is not used by the aplication (i.e. removed by the linker). However if FormatName is used then the debugger will be able to reflect it's value (in a debug build).

That's "in line" with other reflection usage, i.e. the linker do not consider them, but you can preserve them manually (with attribuets or an xml file).

OTOH we _could_ add the code to the linker for this specific case. I'm not convinced it's worth the extra time (at least not in the 2.10 linkercode base). Changing to enhancement and c.c. Miguel.
Comment 7 Marek Safar 2013-01-31 15:32:47 UTC
No need to special case FormatName, the DebuggerDisplay is document and used by all Mono collections classes for instance
Comment 8 Sebastien Pouliot 2013-01-31 15:54:14 UTC
You misunderstood. I was not talking about special casing `FormatName` in the linker. That's definitively would be a waste of time (and there are already ways for people to do so).

I'm talking about adding code to handling the string value of any [DebuggerDisplay] to mark the properties, fields or methods inside that type. So far the linker ignore reflection usage (generally because it's impossible to get 100% right when strings are used). This case is more limited (in context) so it could be done.

Also the NEEDINFO status was intended for Miguel (for the "if and when" to implement this).
Comment 9 Marek Safar 2013-01-31 15:56:07 UTC
You could "just copy" the logic from MD which has the handling implemented.
Comment 10 PJ 2013-11-19 17:04:23 UTC
This bug has been in the NEEDINFO state with no changes for the last 90 days. Can we put this back into the NEW or CONFIRMED state, or are we still awaiting response?

If there is no change in the status of this bug over the next two weeks, this bug will be marked as NORESPONSE.
Comment 11 PJ 2013-12-05 18:34:24 UTC
This bug has not been changed from the NEEDINFO state since my previous comment, marking as RESOLVED NORESPONSE.

Please feel free to REOPEN this bug at any time if you are still experiencing the issue. Please add the requested information and set the bug back to the NEW (or CONFIRMED) state.