[FEATURE] Upgrade SkiaSharp.Views.WinUI to 1.8

[dotMorten]

Is your feature request related to a problem?

Please upgrade the WinUI package to reference Microsoft.WindowsAppSDK.WinUI 1.8, so that it no longer relies on the Microsoft.WindowsAppSDK metapackage that'll force you and any other library that depends on Skia (like .NET MAUI) to pull in the entire metapackage.

Describe the solution you would like

Reduce WinAppSDK dependency to only rely on the WinUI package

Describe alternatives you have considered

Additional context

No response

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

[github-actions[bot]]

Triage Summary

Labels will be applied to indicate the affected area (SkiaSharp.Views) and the specific operating system (Windows-WinUI) due to a request for upgrading the SkiaSharp.Views.WinUI package.

This issue is not a regression, but rather a feature request focusing on package updates.

Additional remarks:

• The issue does not relate to compatibility, performance, or reliability, which is why no additional relevant labels were selected.
• The feature request specifically pertains to upgrading a package related to WinUI, which does not align with the backend labels focused on graphics APIs or formats.

Detailed Summary and Actions

Summary of the triage:

• The issue is specifically requesting an upgrade to the SkiaSharp.Views.WinUI package.
• This upgrade request is relevant to the SkiaSharp.Views area of the project.
• It also aligns with the Windows-WinUI operating system label.

Summary of the actions that will be performed:

Action	Item	Description
Apply Label	area/SkiaSharp.Views	The issue specifically requests an upgrade to the SkiaSharp.Views.WinUI package.
Apply Label	os/Windows-WinUI	The issue mentions upgrading a WinUI package, aligning with the Windows-WinUI label.

This entire triage process was automated by AI and mistakes may have been made. Please let us know so we can continue to improve.

[jeromelaban]

This kind of change has always strings attached, as it requires all consumers to upgrade to the latest.

If it's only for a question of download size, it might not be enough to force everyone to upgrade to 1.8.

[dotMorten]

@jeromelaban then stay on the previous version? Not doing this has the downside effect that you can’t reduce your dependencies down the stack but will forever be required to reference the full meta package. The meta package becomes a viral dependency even though nothing in the stack required anything but the WinUI package. It’s a bit on all us 3rd party library developers to fix the low level dependencies first so higher-level projects can reap the benefits

[jeromelaban]

It is on all of the third-parties to help, but not necessarily on the cost of making using the SkiaSharp more difficult in case an important update comes along. (e.g. 1.8 breaks some maui features with net10-rc1+WebView2).

@mattleibow will determine, but in general, I find it best to keep dependencies as low as possible (unless something breaks badly or improves features significantly), in order to leave the choice of the dependency version to upgrade when required and not be pushed in a dependency management conundrum.

[dotMorten]

I find it best to keep dependencies as low as possible

I completely agree.

unless something breaks badly or improves features significantly

Which is the case here. As you said yourself it's about choice of dependency, and the current state means your choice is now limited and you're being forced to pull everything in. In addition, the build errors you get aren't helpful at all, so I'd like to argue this will actually help with dependencies to some extent.

1.8 breaks some maui features with net10-rc1+WebView2

1.8 upgrade is planned for RC2, but it can't be done right without this.

[jeromelaban]

Which is the case here. As you said yourself it's about choice of dependency, and the current state means your choice is now limited and you're being forced to pull everything in. In addition, the build errors you get aren't helpful at all, so I'd like to argue this will actually help with dependencies to some extent.

I would think the build errors (and their troubleshooting) are a burden on WinAppSDK to handle and document, not third party libraries that depend on the meta package...

1.8 upgrade is planned for RC2, but it can't be done right without this.

Do you mean that MAUI RC2 can't happen if SkiaSharp is not updated to avoid using the meta package?

[dotMorten]

I would think the build errors (and their troubleshooting) are a burden on WinAppSDK to handle and document,

This has nothing to do with the WinAppSDK, but with how NuGet and metapackages work. The only thing we can blame the WinAppSDK team was how long it took them to split up the packages. Now that it is finally done, it's on us to take advantage of it, and unblock the rest of the ecosystem to do the same thing.

Do you mean that MAUI RC2 can't happen if SkiaSharp is not updated

I mean it can't happen the right way. You'll continue to be forcing meta package requirement on anything down-stream. If you move to 1.8, you should stop using the metapackage all-together, but MAUI can't because other dependencies hasn't done the same thing. That's exactly why the dependencies have to do it first and then work your way up the dependency stack.