ListvewExtensionsPage Command prop not found

CommunityToolkit / WindowsCommunityToolkit

The Windows Community Toolkit is a collection of helpers, extensions, and custom controls. It simplifies and demonstrates common developer tasks building .NET apps with UWP and the Windows App SDK / WinUI 3 for Windows 10 and Windows 11. The toolkit is part of the .NET Foundation.

https://docs.microsoft.com/windows/communitytoolkit/

Other

5.89k stars 1.38k forks source link

ListvewExtensionsPage Command prop not found #4039

Closed Rosuavio closed 3 years ago

Rosuavio commented 3 years ago

Describe the bug

A clear and concise description of what the bug is. After building the sample app locally (Debug|x64) when opening the ListViewExtensions sample the sample app crashes with the error

Windows.UI.Xaml.Markup.XamlParseException
  HResult=0x802B000A
  Message=The text associated with this error code could not be found.

Cannot deserialize XBF metadata property list as 'Command' was not found in type 'Microsoft.Toolkit.Uwp.UI.ListViewExtensions'. [Line: 0 Position: 0]
  Source=<Cannot evaluate the exception source>
  StackTrace:
<Cannot evaluate the exception stack trace>

[ ] Is this bug a regression in the toolkit? If so, what toolkit version did you last see it work:

Steps to Reproduce

[ ] Can this be reproduced in the Sample App? (Either in a sample as-is or with new XAML pasted in the editor.) If so, please provide custom XAML or steps to reproduce. If not, let us know why it can't be reproduced (e.g. more complex setup, environment, dependencies, etc...)

Steps to reproduce the behavior:

In the sample app
Open the ListViewExensionsPage sample
See error

Expected behavior

A clear and concise description of what you expected to happen. Sample opens

Screenshots

If applicable, add screenshots to help explain your problem.

Environment

NuGet Package(s):

Package Version(s):

Windows 10 Build Number:
- [ ] Fall Creators Update (16299)
- [ ] April 2018 Update (17134)
- [ ] October 2018 Update (17763)
- [ ] May 2019 Update (18362)
- [ ] May 2020 Update (19041)
- [ ] Insider Build (build number: )

App min and target version:
- [ ] Fall Creators Update (16299)
- [ ] April 2018 Update (17134)
- [ ] October 2018 Update (17763)
- [ ] May 2019 Update (18362)
- [ ] May 2020 Update (19041)
- [ ] Insider Build (xxxxx)

Device form factor:
- [ ] Desktop
- [ ] Xbox
- [ ] Surface Hub
- [ ] IoT

Visual Studio
- [ ] 2017 (version: )
- [ ] 2019 (version: )
- [ ] 2019 Preview (version: )

Additional context

Add any other context about the problem here.

ghost commented 3 years ago

Hello RosarioPulella, thank you for opening an issue with us!

I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌

Rosuavio commented 3 years ago

@deanchalk and @Sergio0694, maybe you can us investigate whats going on here.

Sergio0694 commented 3 years ago

Mh, this is odd, the ListViewExtensions sample page is working just fine for me with the app from the Store. Clicking on items also works correctly, invoking the command that's bound through the extension. Were you using the Store version or a local build? If it was a local build, this was with .NET Native in Release mode I assume? 🤔

Rosuavio commented 3 years ago

Were you using the Store version or a local build? If it was a local build, this was with .NET Native in Release mode I assume? 🤔

I should have mentioned, Local build, Debug|x64

michael-hawker commented 3 years ago

This seems similar to the issue we were seeing before with Menu as well. Which all work fine in Release mode I believe in the store app. So this may be an SDK issue?

We probably need to construct a small repo with XamlReader in an app to open an issue on WinUI?

IsmailHassani commented 3 years ago

I have the same issue.\ As soon i use an ICommand or Attached property with iCommand in a ListView you get this error.\ I posted this issue on Discord post a while ago, but it seems this issue was causing the problem initially why i couldn't upgrade to version 7.0.2.\ If i go back to version 6.1.1 the issue is gone.

These are the errors i get:

Windows.UI.Xaml.Markup.XamlParseException: The text associated with this error code could not be found. Cannot deserialize XBF metadata property list as 'DoubleTappedCommand' was not found in type 'ISynergy.Framework.UI.Controls.ListViewAttached'

and

Windows.UI.Xaml.Markup.XamlParseException: The text associated with this error code could not be found. Cannot deserialize XBF metadata property list as 'Command' was not found in type 'Microsoft.Xaml.Interactions.Core.InvokeCommandAction'.

michael-hawker commented 3 years ago

Wondering if this is related or the same as https://github.com/microsoft/microsoft-ui-xaml/issues/4614 as we did take the dependency on WinUI 2.5 at that time.

We probably need a small sample with just our Toolkit ICommand ListViewExtension helper in an app, see if it works. Then add WinUI 2.5 dependency and resources in and see if it breaks...

@RosarioPulella once you're done with the UI Tests, want to see if you can test this out in a file new UWP app and see what happens? Then if we have a repro showing its at least related to WinUI, we can attach to the above issue and raise with the WinUI team for 2.6.

Arlodotexe commented 3 years ago

I managed to trigger (x64, Debug) this in my own app after making changes in the configuration manager and updating a few Uno packages.

I have a hunch that this may be related to VS 16.10 in some way. If I can confirm it, it'll be the third tooling issue broken by 16.10 today alone 😅

Edit: I'm getting a different error message now related to Command being missing from InvokeActionCommand. Could be related, but this shows on 16.9 as well 🤷‍♂️

IsmailHassani commented 3 years ago

There is definitely something strange happening. I just noticed that one assembly is not referenced. The "Microsoft.UI.Xaml.Markup" library.

working version:

Non-working version:

I'm also missing the file "Microsoft.UI.Xaml.Markup.winmd" in the generated output of the failing application. However, adding this reference doesn't solve this issue.

michael-hawker commented 3 years ago

FYI @ranjeshj @StephenLPeters - does this seem like the linked WinUI bug or something else you may be tracking?

StephenLPeters commented 3 years ago

hmm, I wonder if @alwu-msft might know what this is.

evelynwu-msft commented 3 years ago

On the surface they do appear similar, although the fact that it only appears to be broken in Debug builds is a wrinkle. What happens if you add <EnableTypeInfoReflection>false</EnableTypeInfoReflection> to the project and build as Debug?

(@RealTommyKlein as FYI)

RealTommyKlein commented 3 years ago

Pretty sure this is the linked bug I opened against WinUI 2, microsoft/microsoft-ui-xaml#4614 (or at least the error message is idewntical) - @michael-hawker and I had an email thread about it titled "Issue with ICommand Binding in UWP Debug Mode" and the error message/repro is identical to the issue I'd investigated.

michael-hawker commented 3 years ago

Thanks @RealTommyKlein for the reminder! I had forgotten about that thread from before I was on a vacation in April. Yeah this still seems related then, we had just opened this issue on GitHub later for our own tracking.

I'm not sure what impact of your proposed workaround would have on the Toolkit (and its binary size), do you think a fix will be coming in WinUI 2.6 (as we do plan to update the dependency for our next revision)? Would it be helpful for us to confirm or try anything else on our side (like setup an isolated project which shows adding WinUI 2.5 causes the issue)?

FYI @alwu-msft we did confirm that we already should have EnableTypeInfoReflection turned off:

https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/afcf18f0a77a15a95cd6bdd03a962a282c6e899c/Directory.Build.props#L45-L51

RealTommyKlein commented 3 years ago

I don't think it's fixed for WinUI 2.6, but @ranjeshj can confirm. For putting the workaround in the toolkit (and its samples), the size impact would be minimal and would allow the WCT sample apps to run, but it could still be hit by other external apps which consume WCT and use ICommand themselves. Also forgot to mention this in my original reply, but I can also confirm that EnableTypeInfoReflection is disabled across the entire WCT repo.

Rosuavio commented 3 years ago

I'm not sure what impact of your proposed workaround would have on the Toolkit

@michael-hawker I would like to try this proposed workaround, but I could not find any mention of one anywhere. Can you elaborate so I can try it out locally?

XAML-Knight commented 3 years ago

I'm still hitting this error when testing WinUI 2.6 (x64, Debug, VS 16.10.2).

I am able to successfully open ListViewExtensions when I switch to Release mode, however.

There is an issue on my dev laptop with the WindowsDesktop SDK:

IsmailHassani commented 3 years ago

Hi guys, me again. I found another strange thing. To clarify some stuff, i'm using an own Mvvm library which has an Command and Command{T} class. This library is multiplatform and generates a .net standard (for UWP) and a .net 5.0 library. The Command is inheriting the System.Windows.Input.ICommand interface which seems totally different based on the framework i'm using.

Net standard 2.0
- C:\Users\IsmailHassani.nuget\packages\netstandard.library\2.0.3\build\netstandard2.0\ref\netstandard.dll (2.0.0.0)
Net 5.0
- C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\5.0.0\ref\net5.0\System.ObjectModel.dll (5.0.0.0)
UWP:
- C:\Users\IsmailHassani.nuget\packages\microsoft.netcore.universalwindowsplatform\6.2.11\ref\uap10.0.15138\System.ObjectModel.dll (4.1.1.0)

When i analyze the Microsoft.Xaml.Behaviors package, it uses

C:\Users\IsmailHassani.nuget\packages\system.objectmodel\4.0.12\ref\netcore50\System.ObjectModel.dll (4.0.10.0) which is on it's own a totally other version.

Could this be the issue why we get all these ICommand/Command errors?

michael-hawker commented 3 years ago

This was fixed as part of #4182 with the fix from WinUI 2.6.2