Adding SettingsControls package to Microsoft.WindowsAppSDK 1.4 project stops ItemsView to work

[RobertK66]

Describe the bug

My Project uses Microsoft.WindowsAppSDK 1.4 and the new ItemsView Control.

When adding the CommunityToolkit.WinUI.Controls.SettingsControls (8.0.230907) package as new dependency the working ItemsView does not longer initialize. It crashes with:

WinUi3Test.exe: WinRT originate error - 0x802B000A : 'Failed to assign to property Microsoft.UI.Xaml.Controls.ItemsRepeater.ItemTransitionProvider'

Steps to reproduce

- Use a new ItemsView Control in Windows App SDK 1.4 (1.4.230822000) application.
- bind to an ItemsSource and test correct behavior.
- add reference to  CommunityToolkit.WinUI.Controls.SettingsControls (8.0.230907)
- rebuild solution
- Retest -> ItemsView crashes with above error message.

see also: microsoft/microsoft-ui-xaml#8810
see this repo for reproducing the crash: https://github.com/RobertK66/SettingsExpanderExample/tree/issue/sdk_8810

Expected behavior

ItemsView should work as before adding reference.

Screenshots

No response

Code Platform

• UWP
• WinAppSDK / WinUI 3
• Web Assembly (WASM)
• Android
• iOS
• MacOS
• Linux / GTK

Windows Build Number

• Windows 10 1809 (Build 17763)
• Windows 10 1903 (Build 18362)
• Windows 10 1909 (Build 18363)
• Windows 10 2004 (Build 19041)
• Windows 10 20H2 (Build 19042)
• Windows 10 21H1 (Build 19043)
• Windows 10 21H2 (Build 19044)
• Windows 10 22H2 (Build 19045)
• Windows 11 21H2 (Build 22000)
• Other (specify)

Other Windows Build number

Windows 11 Pro 22H2 22621.2134

App minimum and target SDK version

• Windows 10, version 1809 (Build 17763)
• Windows 10, version 1903 (Build 18362)
• Windows 10, version 1909 (Build 18363)
• Windows 10, version 2004 (Build 19041)
• Windows 10, version 2104 (Build 20348)
• Windows 11, version 22H2 (Build 22000)
• Other (specify)

Other SDK version

No response

Visual Studio Version

2022

Visual Studio Build Number

No response

Device form factor

Desktop

Additional context

I found a fix/workaround by manually adding the CommunityToolkit.WinUI.Controls.Segmented package !

it seems there is a unwanted/unsatisfied transient dependency here ...

Help us help you

Yes, but only if others can assist.

[pluto-dev]

It's not just the SettingsControl. I get the exception simply by adding CommunityToolkit.WinUI.UI.Controls.Core Version="7.1.2" to my project.

[michael-hawker]

The SettingsControl doesn't have anything to do with the Segmented control. The piece they share as dependency are the Extensions project, curious if adding that would resolve anything, but if anything NuGet should be installing all these anyway...

Though we have seen other weird issues with UWP CommunityToolkit/Tooling-Windows-Submodule#79, but WASDK was working fine.

@pluto-dev the 7.1.2 version was compiled against an even older version of the WASDK. The Settings Control was compiled against 1.3 as 1.4 was just released, we didn't want to force folks to have to update.

@RobertK66 was there any warnings from NuGet about package downgrades?

I think we need to see what the platform team says, as we tested, in general, a 1.4 app using our 1.3 built package, which should be a supported scenario, I thought.

[RobertK66]

@michael-hawker :

• No, the package installes without any warning:

Das NuGet-Paket "CommunityToolkit.WinUI.Controls.SettingsControls 8.0.230907" wird installiert.
Die Assetdatei wird auf den Datenträger geschrieben. Pfad: C:\dev\SettingsExpanderExample\WinUi3Test\obj\project.assets.json
"CommunityToolkit.Common 8.2.1" wurde erfolgreich auf "WinUi3Test" installiert.
"CommunityToolkit.WinUI.Controls.SettingsControls 8.0.230907" wurde erfolgreich auf "WinUi3Test" installiert.
"CommunityToolkit.WinUI.Extensions 8.0.230907" wurde erfolgreich auf "WinUi3Test" installiert.
"CommunityToolkit.WinUI.Helpers 8.0.230907" wurde erfolgreich auf "WinUi3Test" installiert.
"CommunityToolkit.WinUI.Triggers 8.0.230907" wurde erfolgreich auf "WinUi3Test" installiert.
Das Ausführen von NuGet-Aktionen hat 188 ms. gedauert.
Verstrichene Zeit: 00:00:00.3346635
========== Abgeschlossen ==========

• only adding "CommunityToolkit.WinUI.Extensions 8.0.230907" does NOT do the trick! Crashes with same error.

• when adding "CommunityToolkit.WinUI.Controls.Segmented 8.0.230907" there are no other dependencies installed.

Das NuGet-Paket "CommunityToolkit.WinUI.Controls.Segmented 8.0.230907" wird installiert.
Die Assetdatei wird auf den Datenträger geschrieben. Pfad: C:\dev\SettingsExpanderExample\WinUi3Test\obj\project.assets.json
"CommunityToolkit.WinUI.Controls.Segmented 8.0.230907" wurde erfolgreich auf "WinUi3Test" installiert.
Das Ausführen von NuGet-Aktionen hat 62 ms. gedauert.
Verstrichene Zeit: 00:00:00.1948253
========== Abgeschlossen ==========

[RobertK66]

just made a quick re-test with yesterdays version (1.4.230913002) of WinAppSdk. Nothing changed. Problem still exists.

[michael-hawker]

just made a quick re-test with yesterdays version (1.4.230913002) of WinAppSdk. Nothing changed. Problem still exists.

Thanks @RobertK66 that's great info for us to know. I've raised the corresponding bug up with the platform team for assistance in this space since the crash is happening within the SDK. Also, since others have had packages of ours from 2 years ago and seen the same results, it's hard for us to know anything we're doing specifically that would be the root cause here as those packages are built entirely differently than the ones we have now. Hopefully, they can help us figure out what's going on here soon. 🤞

[RobertK66]

I think I found the cause of this issue.
See this repository: https://github.com/RobertK66/WinUi3

Steps to reproduce:

• make a Windows App SDK 1.4 Application using ItemsView Control
• crate a WinUI 3 Class Library Project (Name it with with starting Letter 'A...' ! Keep the current template reference to Win App SDK 1.3!)
• add a CustomControl and make usage of Microsoft.UI.Xaml.Controls.ItemsRepeater in its ControlTemplate

-> This now creates the described crash. (Note that my example Control does not make any sense at all, but the issue is triggered by loading xaml resources alone - no need to use this control!)

You have 2 options to resolve this from here:
a. The 'magical Healing': Rename the ClassLibrary Project to "Z...". (This is equal to loading other Control dlls with xaml resources and a starting letter sorting them into the first place of dependencies!) -> Rebuild solution. -> all ok.
b. Make the Class Library compile against Win App 1.4 -> also solves the issue.

I think the underlying problem is, that the first dll getting its resources loaded can decide which version of the ItemsRepeater gets used by all others !!???

[michael-hawker]

Thanks for the investigation @RobertK66, that's very interesting. Can you swap your comments around and have the main detail in the microsoft-ui-xaml platform repo (will be easier for them to follow having the core details in their issue)? The platform handles the loading of resources/dll, so it seems like the fix is going to have to go there.

We didn't want to bump our version of the WASDK when we released so people who haven't updated yet could still make use of the controls, we feel this should be a supported scenario. We'll raise this up with the platform team.

[RobertK66]

ok coiped content to microsoft/microsoft-ui-xaml#8810 (comment)

[michael-hawker]

Related to CommunityToolkit/Tooling-Windows-Submodule#160

[michael-hawker]

@RobertK66 the latest main build should be updated now, so this should be resolved using those packages. The platform issue still exists: microsoft/microsoft-ui-xaml#8810 - so any new components could introduce this issue again in the future. But for now, we should hopefully be aligned. Let us know if you encounter any other issues. Thanks!

[RobertK66]

Thx. for this info. Waiting to see the platform improvements here ...

To be honest, this issue was one of the contributing facts which finally brought me to abandon my 'developer plan' to use Win Ui 3 in some major new projects of mine. It seems to me that the underlying UI platform - with its 1.6k open issues!, and its 'strange' github source code and develop visibility - unfortunately does not really live up to the stated "Windows App SDK Family Promise" . Also at this time it is not clear to me if it gets enough investment from Microsoft to really be the 'future of Application Development for Windows'.

Still using it for some hobby projects and looking forward to new releases 😄 !

[michael-hawker]

This is still an issue moving forward with the Windows App SDK, but the 8.1-rc packages are built against 1.5, so they are available for folks to be compatible.

[RobertK66]

To get rid of the -rc package I tested my app with
<PackageReference Include="Microsoft.WindowsAppSDK" Version="1.6.240807006-preview1" />
with either
<PackageReference Include="CommunityToolkit.WinUI.Controls.SettingsControls" Version="8.0.240109" />
or
<PackageReference Include="CommunityToolkit.WinUI.Controls.SettingsControls" Version="8.1.240606-rc" />

In both cases the crash is avoided. But now I also stumbled over this new issue: #473 !

also reported here: microsoft/WindowsAppSDK#4649

[RobertK66]

Not sure if anybody ever reads developer rants on closed issues but in continuing this

To be honest, this issue was one of the contributing facts which finally brought me to abandon my 'developer plan' to use Win Ui 3 in some major new projects of mine. It seems to me that the underlying UI platform - with its 1.6k open issues!, and its 'strange' github source code and develop visibility - unfortunately does not really live up to the stated "Windows App SDK Family Promise" . Also at this time it is not clear to me if it gets enough investment from Microsoft to really be the 'future of Application Development for Windows'.

I have to state here:

I really appreciate the recent improvements of the "github usage" over at https://github.com/microsoft/microsoft-ui-xaml
With the availability of the 3 Branches

• https://github.com/microsoft/microsoft-ui-xaml/tree/winui3/release/1.6-stable (or main)
• https://github.com/microsoft/microsoft-ui-xaml/tree/winui3/release/1.5-stable
• https://github.com/microsoft/microsoft-ui-xaml/tree/winui3/release/1.4-stable

mirroring some internal real work repositories, i was able to find the code bytes that finally fixed microsoft-ui-xaml#8810:

Thx. for that. So finally as a developer I am happy to put this case to rest now 😄 ...

... thinking of the source code comment words '.. work around ..' one could continue to construct a scenario where multiple custom libraries using each other and compiled against different versions still could hit this problem. In absence of a more sophisticated Metadata/XAML versioning concept (or is there one?) maybe it would be better to sort the rest of this this array by SDK version number descending. Just my 2 cts. 🤣