Bug 1841 - Regression in displaying Dictionary type in watch window
Summary: Regression in displaying Dictionary type in watch window
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Debugger ()
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2011-11-02 15:14 UTC by Marek Safar
Modified: 2011-12-07 15:12 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Screenshot (174.76 KB, image/png)
2011-12-03 05:22 UTC, Marek Safar

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 2011-11-02 15:14:08 UTC
Declare and initialise a variable of type Dictionary<int, string>

When hover over the variable or use watch window Keys and Values properties are both displayed 4 times and IsReadonly twice
Comment 1 Miguel de Icaza [MSFT] 2011-11-14 15:58:56 UTC
This works with Mono 2.10.6 and MonoDevelop 2.8.2

This is probably a Mono/master

This is the sample I tried:

using System.Collections.Generic;
using System.Globalization;
using System;

class A
    public static void Main ()
		var d = new Dictionary<int,string> ();
		Console.WriteLine (d);
Comment 2 Zoltan Varga 2011-11-19 18:19:43 UTC
I can't reproduce this with md master/mono master.
Comment 3 Zoltan Varga 2011-12-02 21:45:50 UTC
Marek, does this problem still happens ?
Comment 4 Marek Safar 2011-12-03 05:22:25 UTC
Created attachment 992 [details]
Comment 5 Zoltan Varga 2011-12-03 06:19:26 UTC
I can repro this now. strange.
Comment 6 Zoltan Varga 2011-12-04 20:24:05 UTC
I'm not sure this is really a runtime problem/regression, the Dictionary class really has 3 Value properties for example:

		ICollection<TValue> IDictionary<TKey, TValue>.Values {
			get { return Values; }

		IEnumerable<TValue> IReadOnlyDictionary<TKey, TValue>.Values {
			get { return Values; }

		public ValueCollection Values {
			get { return new ValueCollection (this); }
Comment 7 Marek Safar 2011-12-05 03:43:40 UTC
There is only 1 Value property the other two cannot be accesses via Value directly and should not be displayed in this case.
Comment 8 Zoltan Varga 2011-12-05 04:03:23 UTC
-> md for now.
Comment 9 Jeffrey Stedfast 2011-12-05 17:54:19 UTC
I'm not able to reproduce this... is it some sort of race somewhere?

I only see the public versions of 'Values' and the other properties unless I drill down into the "Non-public members" folder icon dingus, and then it shows the other 2.
Comment 10 Jeffrey Stedfast 2011-12-05 18:11:44 UTC
Okay, I'm seeing it now (sorta).

Part of the problem is that you guys must have the "Group non-public members" disabled in your debugger preferences.

However, there *is* a bug here in that the System.Collections.Generic.Dictionary interfaces are showing up twice for Keys, Values, and IsReadOnly (presumably one of each is a mislabeled S.C.Dictionary implementation).
Comment 11 Mikayla Hutchinson [MSFT] 2011-12-05 18:27:23 UTC
In addition to some non-public members being marked as explicitly implemented members of the wrong interface, the explicitly implemented ICollection members are not marked as explictly implemented.

For example, looking at a subset of the members we show as non-public:

Keys (System.Collections.Generic.IDictionary<TKey,TValue>)
Keys (System.Collections.Generic.IDictionary<TKey,TValue>)

They should actually be rendered as:

Keys (System.Collections.Generic.IDictionary<TKey,TValue>)
Keys (System.Collections.IDictionary)
IsSynchronized (System.Collections.ICollection)

Or, to match the VS rendering/sorting:

Comment 12 Marek Safar 2011-12-06 04:09:41 UTC
Agree, explicitly implemented members should be displayed as fully qualified. Although it can be tricky for generic types
Comment 13 Jeffrey Stedfast 2011-12-06 12:10:04 UTC
It's actually worse than what mhutch describes...

what we show now:

Keys (System.Collections.Generic.Dictionary<TKey,TValue>)
Keys (System.Collections.Generic.Dictionary<TKey,TValue>)

Note that we don't show *IDictionary*, we show *Dictionary* because all the fixup logic does is put the DeclaringType string into parens, which is obviously the same for both.

And ugh, I can't get at any of the information I need to actually fix this :-(
Comment 14 Jeffrey Stedfast 2011-12-06 12:29:58 UTC

We need some equivalent of Type.GetInterfaceMap so that we can disambiguate members with the same name.

Unless you know of a way we can already do this with the info we have :-)
Comment 15 Zoltan Varga 2011-12-06 12:46:43 UTC
That can be implemented, however the bug title talks about a regression. Did this really work in some mono/md version ?
Comment 16 Marek Safar 2011-12-06 12:49:53 UTC
I think it worked in the way it showed 1st one (or random one) only. It definitely didn't work properly with full name displayed.
Comment 17 Zoltan Varga 2011-12-06 23:58:39 UTC
Added GetInterfaces () and GetInterfaceMap () methods to TypeMirror on HEAD, and backported the runtime changes to mobile-master in 995e8afb6b3d78598e96ba3e54ceff8bbcd66ebf.
Comment 18 Jeffrey Stedfast 2011-12-07 10:54:41 UTC
Awesome! Thanks Zoltan!
Comment 19 Jeffrey Stedfast 2011-12-07 15:12:07 UTC
Okay, now I feel really bad...

As I was working to take advantage of Zoltan's new API, I discovered that it wasn't really necessary.

It looks like we had the needed info already, all I had to change was the implementation of PropertyValueReference.get_Name to return the full property name as opposed to trimming out the interface prefix from it.


Anyways, fixed in git master.