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 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.
Some code issues/code actions may not be checked if the user wants to ignore these cases. To not make a mess in user's source code a good starting point it would be to support Resharper's commands.
I'm not sure if I understand this one correctly.
If it's about the resharper disable commands it's an 'ongoing' project - new issues should clearly support that and old ones should add the commands.
If it's about the missing gui command for 'disalbe' the code issue here - this is a todo and we need to decide how that can be done.
I don't think that we should support the resharper 'ignore' because that would tie us too strict on the resharper features.
Atm I think we should do:
// NRefactory disable XXX
// NRefactory restore XXX
- but maybe it's better to suppert the code analysis attributes .NET offers. That's the question to decide atm. The suppressmessage attribute is mighty enough to do it.
So this task is in my mind (even is badly phrased) to take (all) most of old unit tests (not future ones, of course) and to see which R# warning can be written that the code action/issue can be disabled. And to add to them to NRefactory.
If that's the request then request about the actions individually - I can never 'proof' if all are in or not. We may've different issues - or slightly different. Which can't be handled etc.
Stuff like RedundantXXXIssue should react on 'RedundantXXX resharper disable keyword' can be solved.
Can be done by category of cases? Like "Invert If" in R# happen to be handled by more actions/code issues inside NRefactory.
Ok seems we're speaking of different things here.
I speak about the ResharperDisableKeyword - what do you mean ?
I think I talk about the same property/keyword.
I meant that R# have 'InvertIf disable keyword' would apply for a class of actions in NRrefactory. So to not create 30 issues on: 'Invert if', 'Invert if and simplify else', etc. I thought it is better to make original meta-issues (assignment issues, code-flow issues, etc.) and these will be made in a big(ger) commit fashion. For remaining issues, separate issues will be defined.
As for my workflow to test/fix them, I will go to unit-tests, I will copy/paste the code outside the unit test, I will see which issue they are showing inside R#, and I will add the ResharperDisableKeyword for them.
Ah ok - so r# issues can react on more than one disable keyword ?
Ah, I rephrased wrong. Many NRefactory issues can work with one R# keyword. And in many cases many „kinds” of the same action can be disabled in R# using one keyword (like the InvertIf I've been taking as a relevant case).
So I've said that is easier for someone with R# (i.e. me) to look to all unit tests (that they mostly match: one file with tests -> to one action) and set for all of them in a category their R# keywords. It will make more sense than to create individual bugs for any class.