Closed marcelwgn closed 2 years ago
Sorry for not responding sooner. I'm not sure. It may have had something to do with what was going on to have it work for WinUI 3 as well. @azchohfi?
I had issues making this build for old versions of the SDK, as well as using VS 2022. I had to bump the version to get it building again. You can still use 2.0.12, since there are no new features in 2.0.13.
Would you say there is a point in investigating why it doesn't build with the 17134 SDK and possibly find a solution for this? Or wouldn't that make much sense moving forward since it's market share is in the low single digit percentage (https://reports.adduplex.com/#/r/2022-01)?
Our plan is to align to 17763 (1809) as an LTS release. This is also what the WindowsAppSDK supports. We bumped up too much as the earlier WindowsAppSDK releases before like 0.8 didn't support it, and we never went back down for 1.0. We'll address that in the upcoming toolkit release. I just need to finish #20 first.
@chingucoding both the UWP and WinUI packages should support down to 17763 now, feel free to try it out on the nightly build and let us know if there's any other issue: https://dev.azure.com/dotnet/CommunityToolkit/_artifacts/feed/CommunityToolkit-MainLatest/NuGet/ColorCode.UWP/overview/2.0.13-build.49
We'll ship a version to NuGet when we hotfix the main Toolkit in the next few weeks as well.
As the title says, was there a specific reason why ColorCode.UWP requires 10.0.18362 with version 2.0.13? I know uap10.0.17134 is very old, but I would be curios as to why the min version was bumped.