Bug: args.Cue in NativeAOT-build has IInspectable type

[4OTbIPE]

Description

When custom handling subtitles in MediaPlaybackItem in UWP on .NET 9, the argument type changes to WinRT.IInspectable in NativeAOT build.

This code in Debug build outputs ImageCue (in the case of my video file, which is correct), and when built in NativeAOT it starts outputting IInspectable.

private void CurrentSubtitle_CueEntered(TimedMetadataTrack sender, MediaCueEventArgs args)
{
    RunOnUIThread(() =>
    {
        DebugText.Text = args.Cue.GetType().Name;
    });
}

Steps To Reproduce

1. Create MediaPlaybackItem object with videofile with subtitles
2. Select TimedTextTrack from embedded subtitles
3. Subscribe to its CueEntered event
4. Output somewhere type of args.Cue in CueEntered event handler

Expected Behavior

args.Cue has the same type in NativeAOT build as in debug-build.

Version Info

.NET: 9.0.7
CsWinRT: 2.2.0
Windows SDK: 10.0.26100

Additional Context

No response

[manodasanW]

If the type itself isn't used, AOT compilation may decide to trim the type and we treat it as a regular object (IInspectable). If you are indeed using the type and are casting that result to the actual type and you are still seeing it trimmed, we introduced a new attribute DynamicWindowsRuntimeCast which will be available soon to help with these scenarios.

[brabebhin]

But why is the trimmer making the assumption that the type will not be used? The args.cue value is set internally by the library (in this case winRT itself). The trimmer cannot know for sure which implementation will be used. This will simply force people to exclude libraries from the trimmer and call it a day. I think winRT libs should be excluded from trimming by default, it's not like the whole implementation is shipped with the app...

[dongle-the-gadget]

We do not have any control over the trimmer at all.

[brabebhin]

I am aware. I was just stating this curious fact about the trimmer.

[Sergio0694]

"But why is the trimmer making the assumption that the type will not be used?"

Because the type of the property is IMediaCue. There is no way for the trimmer to know which concrete type will be instantiated by the native code at runtime. It doesn't see anyone creating ImageCue anywhere, so it considers it not constructed, and trims it away. That produces that issue you're seeing this. Like Mano mentioned, that attribute will work around the issue for now.

In CsWinRT 3.0, things will just work here as long as you'll add an actual cast to ImageCue.

In general, GetType() is not trim-safe for projected types. You should not rely on it being consistent. The only thing we can provide support for is the actual types being correct when you use them. E.g. if you did (ImageCue)args.Cue, that'd be fine (in 3.0).

[brabebhin]

Let me rephrase. I am aware why the trimmer does what it does.

The feedback I'm giving is that the trimmer shouldn't be as aggressive, and simply ignore trimming what it cannot know for sure it won't be used, particularly when dealing with polymorphism and interfaces, like in this case.

[dongle-the-gadget]

In that case trimming is useless because nothing can be trimmed with absolute certainty.

The trimmer relies on trimming annotations in order to determine what can't be trimmed, rather than the opposite. In the case of CsWinRT, there are many cases that can't be determined statically.

(Also this is the wrong place to discuss the trimmer, since it belongs to .NET, not CsWinRT)

[Sergio0694]

Also in general you should just not rely on the runtime type for projected types, as that depends on a lot of things. You should only actually use the code you need to use. For instance, like I said, if you actually need ImageCue, then do an actual runtime cast for it. Don't just get the interface reference and do GetType(), because in that case as far as the linker is concerned, you still don't actually care about a specific type. There's nothing you're doing there that's saying "I actually need this specific type".

[brabebhin]

I think the get type was just for the sake of sample. I think the excepted type was supposed to at least be IMediaCue after trimming, not IInspectable (this still sounds like a bug, you are using the IMediaCue interface in your code and the old dotnet native didn't fall for this trick when trimming).

Blind casting might not always be a good idea, given how winRT is tied around queryInterface.

I think at least in the case of cswinRT that trimming should be less aggressive by default since the projections don't actually include any implementations that would have a significant size gain from trimming. At least when you're projecting a native lib like winRT itself.

[Sergio0694]

"I think the excepted type was supposed to at least be IMediaCue after trimming, not IInspectable"

I think there's a misunderstanding there. IInspectable is a type (the name is misleading). IMediaCue is an interface. It will never show up as a type name if you do GetType(), because it's not a class type. The object you got back does implement IMediaCue. That's why the trimmer could remove types, because in that case it didn't result in an observable behavior change: you still got back an IMediaCue instance you could use exactly in the same way.

[brabebhin]

True, there's definitely a break down in communication. Async over git isn't the best form. Just a small upgrade over carrier pigeons.

I think most of the questions that will come your way will be some variation of "why is this not a problem with dotnet native but it is with nativeAOT" which is basically what this OP also is. And unfortunately for you, cswinrt is the entry point for all those questions. And this question and its variations do have some merit in regards to tooling available for winRT apps with c#. I guess winRT will always be a C++ first implementation and then C#.

[Sergio0694]

I'm not really concerned. This is one of the many problems we're planning on addressing in CsWinRT 3.0 🙂