Debugger should ship DebuggerDisplay strings for system types (autoexp.cs/dll)

[nosami]

DebuggerDisplay attribute not used for dictionary key and value collection display

Steps to Reproduce

Debug code with an object in a Dictionary that has a DebuggerDisplay attribute.
Display the values in the Dictionary in the Locals window, quick watch, or other debugger display
Here's some sample code that demonstrates the issue:

using System.Diagnostics;

class Program
{
    static void Main(string[] args)
    {
        Dictionary<int, Widget> map = new Dictionary<int, Widget>();

        map[1] = new Widget("Photo");
        map[2] = new Widget("Hat");
        map[3] = new Widget("Ocean");

        foreach (var item in map.Values)
        {
            Console.WriteLine(item);
        }

        Debugger.Break();
    }
}

[DebuggerDisplay("{_name}")]
public class Widget
{
    private string _name;
    public Widget(string name)
    {
        _name = name;
    }

    public override string ToString()
    {
        return $"A widget named {_name}";
    }
}

Expected Behavior

The debugger should be using the DebuggerDisplay attribute instead of the ToString() override, when both exist.

Actual Behavior

The problem is that the ToString override is used to display the value: "A widget named Ocean" in the last value.

Logs

OmniSharp log

Post the output from Output-->OmniSharp log here

C# log

Post the output from Output-->C# here

Environment information

VSCode version: 1.69.2
C# Extension: 1.25.4

Mono Information

OmniSharp using mono: 6.12.0

Dotnet Information

.NET SDK: Version: 7.0.200-preview.22628.1 Commit: 76bbaffad6

Runtime Environment:
OS Name: Mac OS X
OS Version: 13.2
OS Platform: Darwin
RID: osx.13-arm64
Base Path: /usr/local/share/dotnet/sdk/7.0.200-preview.22628.1/

Host:
Version: 7.0.1
Architecture: arm64
Commit: 97203d38ba

.NET SDKs installed:
6.0.404 [/usr/local/share/dotnet/sdk]
7.0.100 [/usr/local/share/dotnet/sdk]
7.0.101 [/usr/local/share/dotnet/sdk]
7.0.200-preview.22628.1 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.12 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.1 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.12 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.1 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
x64 [/usr/local/share/dotnet]
registered at [/etc/dotnet/install_location_x64]

Environment variables:
Not set

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download

Visual Studio Code Extensions

Extension	Author	Version
copilot	GitHub	1.71.8269
csharp	ms-dotnettools	1.25.4
remote-containers	ms-vscode-remote	0.245.2
vim	vscodevim	1.24.3
vscode-docker	ms-azuretools	1.23.3

Please paste the output from your clipboard

[gregg-miskelly]

The issue is that, unlike Visual Studio, the C# extension doesn't ship autoexp.dll, that comes with DebuggerDisplay strings for some system types, and those system types don't include them. Because of that these types will be visualized with the ToString implementation. There are two possible ways this could be fixed:

1. The .NET Runtime could add DebuggerDisplay attributes to any system type that has a useful value in autoexp.cs
   -or-
2. The C# extension could ship autoexp.dll as well

If we were starting from the beginning of C#, probably option 1 would make way more sense. Considering where we are, I am not sure.

For anyone looking for a work around: copy the value from Common7\Packages\Debugger\Visualizers\Original\autoexp.cs into your own project. For example:

[assembly: DebuggerDisplay(@"\{[{Key,nq}, {Value,nq}]}", Target = typeof(KeyValuePair<,>))]

[nosami]

Hi @gregg-miskelly, this bug was actually spotted in the context of vsmac, but I filed it here in the hope that it could be fixed in vscode and vsmac simultaneously.

Is there anything that we could do on the vsmac side of things to make this work?

[gregg-miskelly]

No, this will need to be fixed on the vsdbg/vsdbg-ui package side of things.