CsWinRT
CsWinRT copied to clipboard
microsoft
WUX/MUX prototype
Implement prototype WUX/MUX support for both consumption and authoring. The remaining TODO-WuxMux items will provide a better UX or perf but are not required for basic functionality.
Replacement for #1418 that will get CI.
Follow-up notes from @Sergio0694 in the other PR:
We'll need to react to #1395 and have a separate manifest for AOT that only specifies the "latest tested OS version" to allow the Xaml Islands APIs.
Also, we should hook up a linker substitution file to hard-code the UiXamlMode switch when trimming or AOT compiling.
Wanted to clarify the comment I made in #1418. The Windows.UI.Colors class isn’t available in the SDK projection, as it is a WUX type. However, the issue is due to CsWinRT’s behaviors regarding additions, you can’t project Windows.UI.Colors without also projecting Windows.UI.Color, which would conflict with the SDK projection and generate a warning
"The Windows.UI.Colors class isn’t available in the SDK projection, as it is a WUX type. However, the issue is due to CsWinRT’s behaviors regarding additions, you can’t project Windows.UI.Colors without also projecting Windows.UI.Color, which would conflict with the SDK projection and generate a warning"
Given this is a single, well known case, perhaps we can special case it so that when Windows.UI.Colors is projected, we skip also projecting Windows.UI.Color, as we can rely on it already being present in the Windows SDK projections assembly? Or, alternatively, at the very least, perhaps we could generate some type-identity nonsense or whatever to avoid the warning?
"The Windows.UI.Colors class isn’t available in the SDK projection, as it is a WUX type. However, the issue is due to CsWinRT’s behaviors regarding additions, you can’t project Windows.UI.Colors without also projecting Windows.UI.Color, which would conflict with the SDK projection and generate a warning"
Given this is a single, well known case, perhaps we can special case it so that when
Windows.UI.Colorsis projected, we skip also projectingWindows.UI.Color, as we can rely on it already being present in the Windows SDK projections assembly? Or, alternatively, at the very least, perhaps we could generate some type-identity nonsense or whatever to avoid the warning?
Honestly, some manual type identity nonsense isn't the worst idea. I'll try that out in this PR and see what I can do.
Confirmed that data binding and INotifyPropertyChanged works on WUX.
But without XAML codegen it'll still be PITA to use...
I have a try at writing a IXamlMetadataProvider implementation by hand and that is certainly not fun.
The XAML codegen is the work of another team.
From: driver1998 @.> Sent: Tuesday, June 11, 2024 14:44 To: microsoft/CsWinRT @.> Cc: Dongle @.>; Comment @.> Subject: Re: [microsoft/CsWinRT] WUX/MUX prototype (PR #1421)
Confirmed that data binding and INotifyPropertyChanged works on WUX.
But without XAML codegen it'll still be PITA to use...
image.png (view on web)https://github.com/microsoft/CsWinRT/assets/22699485/219d097f-03dc-4a16-8641-0fb49c2bd687
— Reply to this email directly, view it on GitHubhttps://github.com/microsoft/CsWinRT/pull/1421#issuecomment-2160021228, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHBRRWS4I35DJ4FOWPFDKITZG2TERAVCNFSM6AAAAABA4AM53WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRQGAZDCMRSHA. You are receiving this because you commented.Message ID: @.***>
The XAML codegen is the work of another team.
That's the issue I am concerned about right now, that other team might see System XAML as deprecated technology and refuse to update. Just like what happened to ARM64 .NET Framework.