app sdk 1.6 preview1 Breaking Ui ( CommunityToolkit.WinUI.Controls )

microsoft / WindowsAppSDK

The Windows App SDK empowers all Windows desktop apps with modern Windows UI, APIs, and platform features, including back-compat support, shipped via NuGet.

https://docs.microsoft.com/windows/apps/windows-app-sdk/

MIT License

3.85k stars 323 forks source link

app sdk 1.6 preview1 Breaking Ui ( CommunityToolkit.WinUI.Controls ) #4649

Closed jarno9981 closed 3 months ago

jarno9981 commented 3 months ago

Describe the bug

When i updated to App sdk 1.6 preview1 all community toolkit winui controls broke and got removed from the application

Steps to reproduce the bug

install CommunityToolkit.WinUI.Controls.SettingsControls
update to preview 1 app sdk
see all controls break and not show up

Expected behavior

Here see the expected bahavior

Screenshots

ui is fully broken experimantel 2 works and 1 to but it breaks after preview 1

NuGet package version

Windows App SDK 1.6 Preview 1: 1.6.240807006-preview1

Packaging type

Packaged (MSIX)

Windows version

Windows 11 version 22H2 (22621, 2022 Update)

IDE

Visual Studio 2022-preview

Additional context

Visual studio normal and preview both broke the ui

michael-hawker commented 3 months ago

We're still working on testing the Toolkit against 1.6-preview1, see our tracking issue here: https://github.com/CommunityToolkit/Tooling-Windows-Submodule/issues/205

We've heard this from PowerToys as well, so it'll be good to keep this as a tracking issue on the WinUI side.

It's unclear if this is just an issue with version matching and the need for the toolkit to be built against the same version with the fix for https://github.com/microsoft/microsoft-ui-xaml/issues/8810 (ADO 46368821), a regression from that, or something else.

First step is for us to finish getting a clean build of the Toolkit on 1.6-preview1 to investigate more and see if we see this same issue when the versions of the dependent SDK match.

We may have local bits now on 1.6-preview1 (and just our CI still failing); so we're investigating if we see this behavior with that local build. Latest discussion on getting a build from our CI is here: https://github.com/CommunityToolkit/Tooling-Windows-Submodule/pull/195#issuecomment-2293994881

michael-hawker commented 3 months ago

@arlodotexe provided a repro for this scenario with his locally built bits of the WCT built against preview1. I've posted them in the ADO. I can confirm we still see the same behavior mentioned here, so seems like a regression somewhere and most likely independent of the other issues we've had building to this point.

jarno9981 commented 3 months ago

Here is the full repo https://github.com/FirebrowserDevs/FireBrowserWinUi3

jarno9981 commented 3 months ago

Use the experimantel branch amd update sdk then the issue will show

michael-hawker commented 3 months ago

We have an initial build of WCT against preview1 here: https://dev.azure.com/dotnet/CommunityToolkit/_artifacts/feed/CommunityToolkit-PullRequests/NuGet/CommunityToolkit.WinUI.Controls.SettingsControls/overview/8.1.240819-pull-457.1127

jarno9981 commented 3 months ago

Preview 1 wil fix the issues with app sdk Preview 1?

evelynwu-msft commented 3 months ago

This is will be fixed in 1.6 GA.

michael-hawker commented 3 months ago

Thanks @evelynwu-msft and @manodasanW for your help here! Mano provided me the change to the target and I was able to validate this fix on my machine against the preview1 bits. We'll see if we can work to validate the final bits ahead of release as well just to triple-check things look all good.

jarno9981 commented 3 months ago

@michael-hawker i installed the pull version but the controls still break for me @evelynwu-msft

jarno9981 commented 3 months ago

8.1.240820-pull-476.1131

jarno9981 commented 3 months ago

the version mentions ( 8.1.240819-pull-457.1127 and latest pull breaks

michael-hawker commented 3 months ago

@jarno9981 the fix is in the SDK itself not the Toolkit, there are no available bits that you can try directly for this to work for you without going back to the experimental2 release.

When 1.6 releases in full, this will be resolved. I was just commenting that with the fix that has been applied to the SDK that I have validated that everything looks good with the prior and latest bits from the Windows Community Toolkit.

jarno9981 commented 3 months ago

@jarno9981 the fix is in the SDK itself not the Toolkit, there are no available bits that you can try directly for this to work for you without going back to the experimental2 release.

When 1.6 releases in full, this will be resolved. I was just commenting that with the fix that has been applied to the SDK that I have validated that everything looks good with the prior and latest bits from the Windows Community Toolkit. so i need to install experimental 2

jarno9981 commented 3 months ago

@jarno9981 the fix is in the SDK itself not the Toolkit, there are no available bits that you can try directly for this to work for you without going back to the experimental2 release.

When 1.6 releases in full, this will be resolved. I was just commenting that with the fix that has been applied to the SDK that I have validated that everything looks good with the prior and latest bits from the Windows Community Toolkit.

Any eta of the full release of the app sdk 1.6 so now they fix is experimental 2