none
DebuggerTypeProxy strange behaviour

    问题

  • Hi,

    in our company we are working on big project which contains multiple data models. We want to make our day to day debugging life easier and we want to simplify data models debug view by using DebuggerTypeProxy attribude on our class. However I think this attribute will make it even worse. Imagine that you have following structure of your class.

    Wehn you will try to debug code with DebuggerTypeProxy defined on top level following will happen.

    On first level you will see output from DebuggerTypeProxy which is what we want (simplify overview of type). On next level you can expand RawView which will show original content of the type + you can go to base class definition. And here all the problems will start :). As soon as base class level is extended VS will again show content of runtime type over DebuggerTypeProxy which is really strange and confusing, plus RawView is available again. You need to expand RawView if you want to see content of base type. And this will happen on all the way down to base class. So even if DebuggerTypeProxy is defined on top most level of inheritance VS will show it for each and every child class in inheritance model. This will basically bring one extra level which you need to click for each inheritance level. Again very, very confusing.

    Second problem is that when you will expand first RavView in inheritance model you will see all content from DerivedClass + expandable acces to base class (which is ok) and you will see also expandable access to top most class for which DebuggerTypeProxy was configured. Again I somehow don't see reason for this behaviour and it's really confusing that in any inheritance level, access to level on which DebuggerTypeProxy is configured will be available.

    Last problem is related to behaviour described in second point. As for each level you have always access also to top most level something like cyclic dependency will ocure and you will and up with situation where type during debugging don't have end point :). So you can extend it in view over hundreds levels even if inheritance model contains only 2 levels. Without DebugerTypeProxy configured you will be able to expand BaseClass level as very end level.

    Does anybody know what is the reason for this behaviour ? Because of this we don't want to use this attribute at all as it will bring more confusion that benefits. If there any way how to overcome this behaviour ? E.g. DebugerTypeProxy view will be applied only when type on which attribute is assigned is shown in debugger view. All class in inheritance level will not show this extra level. Also last class in inheritance level should be last expandable level in view and there should be no access to top most level.

    For me this behaviour sounds like bug in VS handling and visualization but I want to hear some opinions before I will submit bug report.

    thnx for your help

    J

    2012年2月25日 13:28

全部回复

  • In my understanding, it is for one type, including the inherit types, not just the current class.

    DebuggerTypeProxyAttribute specifies a proxy, or stand-in, for a type and changes the way the type is displayed in debugger windows. When you view a variable that has a proxy, the proxy stands in for the original type in the display.

    For the second question, do you mean this?

    I have not found any documents talked about the Raw View when there's a DebuggerTypeProxy, but now, I do not think so it would be the product "issue".


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us

    2012年2月27日 3:55
    版主
  • Hi Mike,

    thnx for your opinion to this. I understand that DebuggerTypeProxy is defined per type and runtime type is still same when you are extending base level of class. However still don't see any benefit from that. This brings nothing else than confusion and one extra level which you need to expand on the way down for each base class level. Can you think at least about one benefit which this behaviour will bring ?

    For that raw view, yes that's what I mean. And again, if this isn't bug what is the benefit from this behaviour ? Can you think at least about one ?

    thnx

    J


    2012年2月27日 15:03
  • I have found no documents talked this aspect, but based on my understanding, it can told us which class is used the DebuggerTypeProxy attribute, so that we can know the proxy properties's "owner".

    namespace ConsoleApplication32
    {
        class Program
        {
            public static void MethodABC() { }
            static void Main(string[] args)
            {
                var test = new NextDerivedClass();
            }
        }
    
        internal class BaseClass 
        {
            //[DebuggerBrowsable(DebuggerBrowsableState.RootHidden)]
            internal string BaseClassProperty { get; set; }
            //[DebuggerBrowsable(DebuggerBrowsableState.RootHidden)]
            internal string BaseClassProperty1 { get; set; }
            internal string BaseClassProperty2 { get; set; }
            internal string BaseClassProperty3 { get; set; }
        }
    
        
        internal class DerivedClass:BaseClass
        {
            internal string DerivedClassProperty { get; set; }
            internal string DerivedClassProperty1 { get; set; }
            internal string DerivedClassProperty2 { get; set; }
            internal string DerivedClassProperty3 { get; set; }
        }
    
        [DebuggerTypeProxy(typeof(VisualProxy))]
        internal class NextDerivedClass : DerivedClass
        {
            internal string NextDerivedClassProperty { get; set; }
            internal string NextDerivedClassProperty1 { get; set; }
            internal string NextDerivedClassProperty2 { get; set; }
            internal string NextDerivedClassProperty3 { get; set; }
        }
    
        
        internal class NextNextDerivedClass : NextDerivedClass
        {
            internal string NextNextDerivedClassProperty { get; set; }
            internal string NextNextDerivedClassProperty1 { get; set; }
            internal string NextNextDerivedClassProperty2 { get; set; }
            internal string NextNextDerivedClassProperty3 { get; set; }
        }
    
        internal class VisualProxy 
        {
            private NextDerivedClass classIn;
            public VisualProxy(NextDerivedClass classIn) 
            {
                this.classIn = classIn;
            }
            public string VisualProxyProperty2 { get { return this.classIn.NextDerivedClassProperty2; } }
            public string VisualProxyProperty1 { get { return this.classIn.NextDerivedClassProperty1; } }
        }
    }
    And one engineer told me the benefit, "This allows an advanced user to dig for something that they know is there."


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us


    2012年2月28日 13:01
    版主
  • I am writing to check the status of the issue on your side. 
    What about this problem now? 
    Would you mind letting us know the result of the suggestions?

    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us

    2012年3月1日 6:26
    版主
  • Hi,

    I'm not sure which suggestion you mean. If this is about statment that debugger want to visualize who is "owner" I don't think that this is the reason for the behaviour. I'm going to post this question to Microsoft directly and will come back when I will have their response.

    J

    2012年3月2日 16:07
  • It will be good if you can get more "benefits" information, since I just got one as I provided in my post, "This allows an advanced user to dig for something that they know is there.".

    Best wishes,


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us

    2012年3月7日 10:50
    版主