DebuggerTypeProxy types are empty after linking

[eerhardt]

After linking an application, any type that is used by a DebuggerTypeProxyAttribute still exists, but is empty. This is because there are no callers of any of the members on these types - they exist so the debugger can call them to show in the Watch window. So the linker is removing all of the members from the type. But the type remains because it is being referenced by the DebuggerTypeProxyAttribute. This will limit the ability to debug a linked application, because any type that uses a DebuggerTypeProxy will be empty in the Watch window.

We should fix this by annotating the DebuggerTypeProxyAttribute class to tell the linker to preserve its members that are required by the debugger. My initial thinking is that includes PublicConstructors and PublicProperties, as I don't think the debugger will call any methods on the proxy type.

cc @vitek-karas @joperezr @layomia

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. Please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @tommcdon, @krwq
Notify danmosemsft if you want to be subscribed.

[stephentoub]

My initial thinking is that includes PublicConstructors and PublicProperties, as I don't think the debugger will call any methods on the proxy type.

That sounds reasonable; while technically the debugger can show things beyond public properties, every type proxy I've looked at has only public constructors and properties (beyond the private fields that serve those properties). That said, the same argument could be used to say "just keep everything", because there's unlikely to be anything more in the debugger type proxy than public ctors and properties, and if there is, it's likely there for a good debugging reason.

[MichalStrehovsky]

After linking an application, any type that is used by a DebuggerTypeProxyAttribute still exists, but is empty

That's odd because linker has bunch of code that is attempting to do stuff with that attribute.

I'll be happy to replace this with the public dataflow annotations and delete the linker special casing with prejudice.

Unless we get a statement from VS debugging folks on what they can actually use, I would go with .All.

[eerhardt]

That's odd because linker has bunch of code that is attempting to do stuff with that attribute.

It looks like in order to get that code activated, you need to pass -v to the linker command line, which I wasn't.

We should probably come up with a coherent strategy for trimming "debug only" code out.

I think we should have a single "feature switch" that can be turned on/off as necessary.

See

• DynamicDependencyAttribute.Condition and Feature Switches linker#1231 (comment)
• Linking out of debugging support for .NET5 linker#1093
• Define Debugger.IsSupported feature switch to allow trimming of debugger only code. #37288