Having two classes:
[DebuggerDisplay(@"One = {One}, two = {Two}")]
public class A
{
public int One { get; set; }
public B Two { get; set; }
}
[DebuggerDisplay(@"Three = {Three}")]
public class B
{
public int Three { get; set; }
}
Using them:
var a = new A {One = 5, Two = new B {Three = 10}};
Inside the debugger, the tool tip value that is displayed at a
is
One = 5, two = {DebuggerDisplayTest.B}
What I would want is something like
One = 5, two = 'Three = 10'
I know this could be achieved by overriding the ToString()
method of class B
. This just feels not right, since I'm writing code in my application for debugging only.
I also know that using a string similar to
[DebuggerDisplay(@"One = {One}, two = 'Three = {Two.Three}'")]
would work, too. This also does not feel right to me, since it would require that class A
has knowledge of class B
.
I would like to have more of a way to "inject" the value of DebuggerDisplay
of type B
to the instance of that type in class A
.
Is it somehow possible to access the DebuggerDisplay
attribute of a member inside the DebuggerDisplay
attribute of a "has-a" composited class?
Probably, my requirement is not possible as per this SO answer. Maybe a good solution would be to override ToString
in class B
and do some if..else
and use the Debugger.IsAttached
property to behave different only inside the debugger.
Something like:
[DebuggerDisplay(@"Three = {Three}")]
public class B
{
public int Three { get; set; }
public override string ToString()
{
if (Debugger.IsAttached)
{
return string.Format(@"Three = {0}", Three);
}
else
{
return base.ToString();
}
}
}
Piecing together a few things I've come up with this solution. It has the caveat it expects you to follow https://blogs.msdn.microsoft.com/jaredpar/2011/03/18/debuggerdisplay-attribute-best-practices/
[DebuggerDisplay("{DebuggerDisplay,nq}")]
public class B
{
public int Three { get; set; }
private string DebuggerDisplay => $"Three = {Three}";
}
[DebuggerDisplay("{DebuggerDisplay,nq}")]
public class A
{
public int One { get; set; }
public B Two { get; set; }
private string DebuggerDisplay => $"One = {One}, two = {Two.ReadDebuggerDisplay()}";
}
You'll need to make sure you have proper imports for where ever you stick this helper in relation to the code that needs to read child debugger displays.
public static class ReflectionHelper
{
// https://stackoverflow.com/a/13650728/37055
public static object ReadProperty(
this object target,
string propertyName)
{
var args = new[] {CSharpArgumentInfo.Create(0, null)};
var binder = Binder.GetMember(0, propertyName, target.GetType(), args);
var site = CallSite<Func<CallSite, object, object>>.Create(binder);
return site.Target(site, target);
}
public static string ReadDebuggerDisplay(
this object target,
string propertyName = "DebuggerDisplay")
{
string debuggerDisplay = null;
try
{
var value = ReadProperty(target, propertyName) ?? "<null object>";
debuggerDisplay = value as string ?? value.ToString();
}
catch (Exception)
{
// ignored
}
return debuggerDisplay ??
$"<ReadDebuggerDisplay failed on {target.GetType()}[{propertyName}]>";
}
}
I feel like this a pretty fair balance of purity and pragmatism for lowering the friction on achieving this. If you are less concerned about purity you could just make DebuggerDisplay public. I prefer that the ReadDebuggerDisplay operates in a "type-less" manner (avoids generic constraints and interfaces that would be needed to access DebuggerDisplay publicly).
Copied possible solution from OP
Probably, my requirement is not possible as per this SO answer. Maybe a good solution would be to override ToString in class B and do some if..else and use the Debugger.IsAttached
property to behave different only inside the debugger.
Something like:
[DebuggerDisplay(@"Three = {Three}")]
public class B
{
public int Three { get; set; }
public override string ToString()
{
if (Debugger.IsAttached)
{
return string.Format(@"Three = {0}", Three);
}
else
{
return base.ToString();
}
}
}
[Disclaimer I'm affiliated with OzCode]
You can use OzCode's Reveal feature which supports nested debug information.
The plus side is that you do not need to change your production code and once you define it for an instance it would be used automatically for all instances of that type.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With