Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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 332 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
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
When debugging BCL code (e.g. corlib classes) MD debugger treats all conditional code as comments (due to NET_4_0, NET_2_0, etc). This makes it useless because none of the debugger source code features work.
This would happen when the debugger is loading arbitrary files from mdbs. There's not really anything we can do, since we don't have any way to know what combination of defines was used when compiling the code.
Really? Surely stepping into code means that the code was compiled and not commented out. Just do what all other debuggers do.
In order to resolve symbols correctly, we need to parse the file with the same set of defines used when compiling it. Indeed, it's entirely possible for a file not to be parsable unless a subset of defines is used. For simple cases we could guess the defines based on what's in the mdb, I suppose, but it would be hard to guarantee it to be correct.
Probably the best solution would be that we special-case files that aren't in a project - for the tooltips, we'd stop using the resolver and fall back to the inferior and simplistic "does the word under the caret match one of local in the current frame" approach. We'd also need to disable semantic highlighting.
ok, stepping back little bit but comments like we cannot really do anything about it make me sad.
If you think you need a set of defines used for compilation and they are not available from mdb, just assign the bug to mdb or compiler and someone else to make the change. This is not too difficult problem but as you are at the top of the chain you need to drive the bug resolution in some cases.
Marek to put the #define's that were enabled when compiling the assembly so that MonoDevelop can enable those in the editor so that the correct #ifdef blocks are parsed by the resolver (needed for hovering over symbols)
another option would be for MonoDevelop to infer which #defines were enabled based on the line #'s that we have symbol information for.
sounds like we've decided that option #2 is the way to go since we need to work with csc compiled assemblies.
This probably belongs in TextEditor?
No not really the text editor (why should it?).
The defines must be defined in the symbols of the project that is opened. A file belongs to a project and there are the defines that are used to parse it. The editor/parser should do the right job.
(btw. it can be a 'bogus' project - doesn't need to be a real one.)
But fixing that would mean finding the right set of defines - remember an if could be any conditional expression, like :
#if FOO && (!BAR || FOOBAR)
Can vs.net do it ? It's an interesting problem btw - esp if more than one set of defines solves an expression and there is only one 'right' set for the debugging session. I would try to retrieve the right set from the .mdb files - or maybe we can but them into these files ?
btw. just to be clear - it's generally not possible to find the 'right' set of defines just based on 'this if needs to be true' - jumping around in the program flow later on another set of defines may be required.
That may result in re-parsing but also may cause wrong tooltips/completion before the reparse, because the original 'set' that solved the 1st #if was wrong. Therefore getting the right set out of the compilation/debugger symbols is the only thing I can imagine that works.