ItemsView produces Failed to assign to property 'Microsoft.UI.Xaml.Controls.ItemsRepeater.ItemTransitionProvider'. exception
adamfierek opened this issue · comments
Describe the bug
After try to display page with ItemsView, XamlParsingFailed is thrown:
Failed to assign to property 'Microsoft.UI.Xaml.Controls.ItemsRepeater.ItemTransitionProvider'.
Steps to reproduce the bug
Place ItemsView in xaml
Expected behavior
working control
Screenshots
No response
NuGet package version
Windows App SDK 1.4.0: 1.4.230822000
Packaging type
Unpackaged
Windows version
Windows 11 version 22H2 (22621, 2022 Update)
IDE
Visual Studio 2022
Additional context
No response
@adamfierek can you share a small repro project ?
Run into exactly same problem. (same Windows/SDK and VS versions)
Here is a repo-branch (pls. ignore the reponame 😉 : https://github.com/RobertK66/SettingsExpanderExample/tree/issue/sdk_8810
@adamfierek can you share a small repro project ?
Yes, I can, but it's a bit difficult since it works on fresh solution and our current project is so big. I will try to provide repro. Meanwhile can you look at @RobertK66 project? It seems to be the same issue.
Same problem here, seems to be caused when using/referencing: CommunityToolkit.WinUI.UI.Controls
Yes, that's it.
Removing the dependency to CommunityToolkit.WinUI.Controls.SettingsControls from my repos solves/avoids this error.
Not sure what to do to make both controls work in one project yet.....
if I want to make it work AND keep my SettingsControls, I have to manually add the
CommunityToolkit.WinUI.Controls.Segmented nuget package.
(Tested with released version 8.0.230907)
opened: CommunityToolkit/Windows#234 with the toolkit project,
Calling out here that CommunityToolkit.WinUI.UI.Controls is the old package from 7.x built against WASDK 1.0
The CommunityToolkit.WinUI.Controls.SettingsControls is the latest 8.0 package built against WASDK 1.3.
It's weird adding another package would mystically solve this, as they're all built in the same pipeline against the same versions.
This seems like a NuGet or dll resolution issue or something when referencing an older WASDK built library against an app built with the latest (or newer) SDK?
@bpulliam FYI.
I would migrate to 8.0 but there is a lack of features currently used by me comparing to 7.x.
Same here, using only DataGrid 7.x version, finished to use ItemsRepeater, basically the same thing.
The 7.x and 8.x packages of the Toolkit are built completely differently. I don't even think the 7,x DataGrid referenced WinUI 2.x.
The only common thread here is the Windows App SDK and the upgrade to 1.4?
I think it can be closed since we know it's caused by 3rd party reference
I think it can be closed since we know it's caused by 3rd party reference
No, there is nothing specific in the third-party reference causing this. It's not a problem in the third-party library. The stack itself isn't contained within the third-party reference. The fact a version of the package from 2-years ago referencing the WindowsAppSDK v1.0 should mean it's not an issue within the packages themselves. Something with ItemsView or the platforms dependency resolution is broken here. Even if it is, there's literally nothing we could change without the platform team root-causing what's happening here and saying that all packages now need to do X instead with 1.4+.
In either case, this is an issue that should remain open with the platform - there's something going on within the platform itself that is unknown when another NuGet dependency is being added (it could be beyond the scope of the just the Toolkit). It needs to be resolved and is something the platform team needs to investigate. There could be any number of other third-party libraries that are affected, there's no action for us to do right now in the Toolkit on here. Two different packages from us with completely different ways of being built and with completely different code highlight the problem within ItemsView, there's nothing we can even start or go on to know to change to resolve this issue in ItemsView.
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 !!???
(content also copied to : CommunityToolkit/Windows#234 )
unchanged/still an issue in Version 1.4.3 (1.4.231115000).
repos with demo for crash upgraded: https://github.com/RobertK66/WinUi3
Thanks @kmahone for digging into this.
This seems to be a bug with IXamlMetadataProvider implementation.
Looks like an IXMP issue.
Here is what happens:
App references WinAppSDK 1.4
App references LibraryFoo that references WinAppSDK 1.3.
LibraryFoo uses ItemsRepeater.
App loads xaml that includes ItemsRepeater. Xaml Parser looks up metadata for ItemsRepeater from App’s IXMP. The App does not include the definition of ItemsRepeater so it forwards it on to ‘OtherProviders’. OtherProviders references both LibraryFoo IXMP and XamlControlsMetadataProvider. It checks both. It happens to have them in alphabetical order, so it checks LibraryFoo first. Since LibraryFoo DOES know about ItemsRepeater it returns the IXMP for it. But this IXMP is for the 1.3 api surface, so it is missing stuff. When the xaml parser tries to set one of the newer apis, it fails since it does not have the metadata for that property.
If you rename LibraryFoo to ZLibraryFoo it happens to change the sort order in OtherProviders and so the scenario works.
We will need to fix this in the Xaml Compiler so that the generated IXMP works correctly in this scenario. It should ensure that the XamlControlsXamlMetaDataProvider is always first in the list of OtherProviders.
Until this issue is fixed, here is one way to work around the issue.
In your app's csproj file add this property to the first PropertyGroup:
<XamlCodeGenerationControlFlags>DoNotGenerateOtherProviders</XamlCodeGenerationControlFlags>
This will cause the Xaml Compiler to not populate the OtherProviders list. You now need to populate it manually. In your App's constructor, call AddOtherProvider to add each of the IXamlMetadataProviders that were previously being generated. Since you can now control the order you can make sure that XamlControlsXamlMetaDataProvider comes first:
public App()
{
this.InitializeComponent();
this.AddOtherProvider(new Microsoft.UI.Xaml.XamlTypeInfo.XamlControlsXamlMetaDataProvider());
this.AddOtherProvider(new AClassLibrary1.AClassLibrary1_XamlTypeInfo.XamlMetaDataProvider());
}
The downside to this is you need to manually add any new IXMP implementations that your app needs if you add a new dependency to your app.
We will need to fix this in the Xaml Compiler so that the generated IXMP works correctly in this scenario. It should ensure that the XamlControlsXamlMetaDataProvider is always first in the list of OtherProviders.
Until this issue is fixed, here is one way to work around the issue.
In your app's csproj file add this property to the first PropertyGroup:
<XamlCodeGenerationControlFlags>DoNotGenerateOtherProviders</XamlCodeGenerationControlFlags>This will cause the Xaml Compiler to not populate the OtherProviders list. You now need to populate it manually. In your App's constructor, call AddOtherProvider to add each of the IXamlMetadataProviders that were previously being generated. Since you can now control the order you can make sure that XamlControlsXamlMetaDataProvider comes first:
public App() { this.InitializeComponent(); this.AddOtherProvider(new Microsoft.UI.Xaml.XamlTypeInfo.XamlControlsXamlMetaDataProvider()); this.AddOtherProvider(new AClassLibrary1.AClassLibrary1_XamlTypeInfo.XamlMetaDataProvider()); }The downside to this is you need to manually add any new IXMP implementations that your app needs if you add a new dependency to your app.
This issue also reproduces on WindowsAppSDK 1.5 (SelectorBar) with CommunityToolkit controls (etc. SettingsControls) 8.0.2.
I changed to code to use manually add other provides for an temporary solution.
Hello, I have the same issue and I don't understand anything as workaround that was written here. Could you please provide a way to not have this error for a dummy ? thanks
I've created a temporary solution sample project for this issue: Issue8810TemporarySolution.
Hope it will help.
I merged a fix for this issue into internal builds. I expect the fix to ship in WinAppSDK 1.6.
ok, this is in status 'closed' now since 3 weeks ago! I can not find any 1.6 release yet! And here there is no trace of any 1.6 - prerelease either....
I personally find this projects usage of github/github-issues really 'strange'. As a 'contributing consuming' developer I have no Idea at all what's going on and what to expect......
1.6-experimental1 has now been released, on June 4.