Natvis for C++/WinRT doesn't work

[vmilea]

Describe the bug

Natvis for C++/WinRT doesn't work because the *.winmd files aren't deployed alonside the process *.exe. This affects both SDK and user authored types.

Steps to reproduce the bug

1. Create a solution from Blank App, Packaged (WinUI 3 in Desktop) template.
2. Set a breakpoint in App::OnLaunched()
3. Debug and pause at breakpoint.
4. Try to inspect the LaunchActivatedEventArgs argument.

Expected behavior

The debug visualizer shows object properties based on metadata.

Screenshots

Notice the output message. To enable natvis diagnostics see documentation.

NuGet package version

1.1.3

Packaging type

Packaged (MSIX)

Windows version

Windows 11 version 21H2 (22000)

IDE

Visual Studio 2022

Additional context

A workaround is to manually copy the *.winmd files from Microsoft.WindowsAppSDK to the executable folder.

[HO-COOH]

This is 4 months old, and still no reply and nobody else encountered it? Btw, I think it could be solved by modifing the project template to add a custom post build step, that copies the whatever winmd files required to the executable folder

[mgradwohl]

I'm hitting it often.

[torleifat]

Yeah, I encounter this fairly often as well. The workaround mentioned in the report works for some of the stuff, but where I struggle is collections with custom types, or just collections in general.

[ackh]

Enabling diagnostics shows that nativs only searches within the AppX of a packaged app for custom winmd files but not within the folder where the custom winmd files are actually created, i.e. one folder higher.

This does not make sense because, as far as I understand it, the winmd files should not be packaged and shipped as part of the app. They are required at compile time, not at runtime and thus should not be shipped for the same reasons that pdb files aren't shipped. From that perspective, adding a post build step to copy winmd files into the AppX folder isn't a solution.

Therefore, it is save to say that the debugging experience for custom types is broken. Why this does not receive more attention is beyond me. Especially because it seems to be fixable by just changing the search paths for winmd files.

[Scottj1s]

@ackh You're correct, we don't want to load up the AppX folder with debugging support files like pdbs and winmds, which aren't required at runtime. In my experiments, I don't see any Windows App SDK winmd files being copied to the parent of the AppX folder, so I don't think we can rely on that. Fortunately, while the diagnostics don't indicate it, the %TEMP% folder is also searched as a cache location. So, a short-term workaround is to add a custom target that copies all the Windows App SDK metadata to the %TEMP% folder. I've confirmed this works with the LaunchActivatedEventArgs repro, and it doesn't impact the AppX folder.

directory.build.targets:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Target Name="CopyWinAppSdkMetadataToTempFolder" BeforeTargets="PrepareForRun">
        <ItemGroup>
            <MetadataFiles Include="$(_MuxWinmdDir)*.winmd" />
        </ItemGroup>
        <Message Importance="High" Text="Copying Windows App SDK metadata files to TEMP to support C++/WinRT Natvis debugging visualizations" />
        <Copy SkipUnchangedFiles="True" OverwriteReadOnlyFiles="True" SourceFiles="@(MetadataFiles)" DestinationFolder="$(TEMP)" />
    </Target>
</Project>

[torleifat]

@ackh You're correct, we don't want to load up the AppX folder with debugging support files like pdbs and winmds, which aren't required at runtime. In my experiments, I don't see any Windows App SDK winmd files being copied to the parent of the AppX folder, so I don't think we can rely on that. Fortunately, while the diagnostics don't indicate it, the %TEMP% folder is also searched as a cache location. So, a short-term workaround is to add a custom target that copies all the Windows App SDK metadata to the %TEMP% folder. I've confirmed this works with the LaunchActivatedEventArgs repro, and it doesn't impact the AppX folder.

directory.build.targets:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Target Name="CopyWinAppSdkMetadataToTempFolder" BeforeTargets="PrepareForRun">
        <ItemGroup>
            <MetadataFiles Include="$(_MuxWinmdDir)*.winmd" />
        </ItemGroup>
        <Message Importance="High" Text="Copying Windows App SDK metdata files to TEMP to support C++/WinRT Natvis debugging visualizations" />
        <Copy SkipUnchangedFiles="True" OverwriteReadOnlyFiles="True" SourceFiles="@(MetadataFiles)" DestinationFolder="$(TEMP)" />
    </Target>
</Project>

This works for me as well. However I am wondering, are the winmd files for collections located elsewhere?

For instance if I do:
auto numbers = single_threaded_observable_vector<int>({ 1, 2, 3, 4, 5 });
I will still get
Natvis C++/WinRT: Could not find metadata for Windows.Foundation.Collections.IObservableVector`1<Int32>

[Scottj1s]

@torleifat Unfortunately, debug visualization does not support generics (collections). The work to implement this is quite involved, so I can't give any estimate if/when it will be done.

[Scottj1s]

@DefaultRyan any thoughts on supporting generics in the debug visualizer?

[DefaultRyan]

@DefaultRyan any thoughts on supporting generics in the debug visualizer?

Same thoughts as Kenny stated in the linked issue. It's not really a technical barrier, but a time+resources barrier. Even more so lately. We don't have any funding allocated for a feature like this right now. At least, not without some sort of signal that this is an impactful issue for lots of customers.

Could make a fun spare time hack project, and cppwinrt regularly accepts outside contributions.

[torleifat]

@Scottj1s @DefaultRyan Thanks for the insight guys.

Can't speak for anyone but myself with regards to impact on customers, but it does make things a bit harder to debug at least when I am used to being able to inspect collections while debugging. But I am certainly sympathetic to time/resources being a constraint.

[ackh]

@Scottj1s @DefaultRyan

At least, not without some sort of signal that this is an impactful issue for lots of customers.

What strikes me as really odd about this statement is that WinUI and I assume large parts of the Windows App SDK is written in C++/WinRT, isn't it? If Microsoft internally writes that stuff in C++/WinRT, how would the lack of ability to inspect collections in the debugger not be a daily PITA for you guys?

It's just that I'm really having a hard time understanding why we customers need to point out the obvious need for this if you guys have more C++/WinRT code to debug than everybody else. I might be wrong here and Microsoft's code base was authored in C++/CX. At least that would explain the hesitance of releasing it as open source.

[Scottj1s]

@ackh That's a good insight. I've seen a few internal complaints, but nothing compelling. Given that the visualizer is restricted to properties, adding support for generics still wouldn't provide much. You'd see the Size of IMap(View) and IVector(View), but not much else. We'd need to find a new technique to iterate over collections, in order to observe elements as you can with C# client code.