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.
tableview should be tableView in:
public override nint RowsInSection (UITableView tableview, nint section)
=== Xamarin Studio ===
Version 5.8.3 (build 1)
Installation UUID: 25d1d6a6-72c5-479c-b704-f939b8920555
Mono 3.12.1 ((detached/0849ec7)
GTK+ 2.24.23 (Raleigh theme)
Package version: 312010003
=== Apple Developer Tools ===
Xcode 6.3 (7569)
=== Xamarin.iOS ===
Version: 18.104.22.168 (Business Edition)
Build date: 2015-04-09 04:22:08-0400
=== Xamarin.Android ===
Version: 22.214.171.124 (Business Edition)
Android SDK: /Users/Neal/Applications/android-sdk-macosx
Supported Android versions:
2.1 (API level 7)
2.2 (API level 8)
2.3 (API level 10)
3.1 (API level 12)
4.0.3 (API level 15)
4.4 (API level 19)
Java SDK: /usr
java version "1.8.0_40"
Java(TM) SE Runtime Environment (build 1.8.0_40-b25)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
=== Xamarin Android Player ===
Version: Unknown version
Location: /Applications/Xamarin Android Player.app
=== Xamarin.Mac ===
Version: 126.96.36.199 (Business Edition)
=== Build Information ===
Release ID: 508030001
Git revision: 6e8e725e0d689351901c2c70453bfa4ea25e293b
Build date: 2015-04-06 20:31:47-04
Xamarin addins: 051cd5f8c1b5dbfc87eaef80a74aec03f34c60a8
=== Operating System ===
Mac OS X 10.10.3
Darwin iMACRH.local 14.3.0 Darwin Kernel Version 14.3.0
Mon Mar 23 11:59:05 PDT 2015
This is technically a breaking change (code can fail to compile after changing parameter names), so I'm not sure this is worth it (in particular since you can just change the name of the variable yourself in the override if you wish).
In searching our broad code base of a 3 year build out app we have mixed use of these params, some are tableView some are tableview which may have come from the unified conversion tool. So I'm not sure if the conversion to unified "broke" the implementations or what the impact is but the concern should be as to what is in your customer's code now. If I didn't have code analysis turned on to bring this to my attention I would have never noticed it and then of course would have had to catch some bad behavior in the app as a result and try to determine why. I wish I could force all devs working on this project to have code analysis on, if I could do it in the solution that would be great but I don't think I can persist this feature on all devs so any and all future devs would see this issue.
So again, the concerns are:
1) How may are impacted now and don't know it
2) Should it be fixed and flagged in a future build to get corrected?
Created attachment 10820 [details]
I had about 20-30 of these, about 50% of the total methods
(In reply to comment #2)
> In searching our broad code base of a 3 year build out app we have mixed use of
> these params, some are tableView some are tableview which may have come from
> the unified conversion tool. So I'm not sure if the conversion to unified
> "broke" the implementations or what the impact is but the concern should be as
> to what is in your customer's code now. If I didn't have code analysis turned
> on to bring this to my attention I would have never noticed it and then of
> course would have had to catch some bad behavior in the app as a result and try
> to determine why.
The warning "Parameter name differs in base method declaration" can safely be ignored, it's more a code style issue than something broken.
> 1) How may are impacted now and don't know it
This warning is completely harmless, and will not affect your app in any way whether you change your code or not.
> 2) Should it be fixed and flagged in a future build to get corrected?
If we change the base class declaration itself (which is the only thing we technically can do), then it is theoretically possible that other apps from other customers will fail to compile after upgrading. This is a serious consequence, and not worth it for an issue that is otherwise completely harmless.
Thanks for the info Rolf. The hover tip is a Warning (see screenshot, hint message is faded) - the source analysis folks may want to change this to a naming suggestion then. It seemed more critical based on the hint associated, I consider "most" of source analysis suggestions NOT code styling but actual .NET compiler related and with this one producing a warning and potentially a compiler warning (yellow item in top center IDE area) during build it seemed more critical in nature.
Rolf - I'm going to reopen this, I do believe this generated a compiler warning so it's going to require action on Xamarin's part in either changing the warning to a naming suggestion or fix the problem that is high enough to be marked as a compiler warning.
Can you attach the build log so that we can have a look at the exact warning message?
Created attachment 10839 [details]
I stand corrected, it does NOT generate a "compiler" warning but a source analysis warning. I navigated to the rule per the attached image. I'll re-close this case. Thank you.