fix windows-sdk+maui9 issue

[jasells]

Sets the floor win-sdk versions per TFM target in the WinUI project to avoid conflicts with other consuming frameworks (Maui9 specifically). Also documents the supporting source docs and various win-sdk floors per TFM.

Issues Resolved

• fixes #669

API Changes

None (bould config only)

Platforms Affected

• WinUI
• Maui

Behavioral/Visual Changes

None (resolved build errors for apps targeting Maui9)

Before/After Screenshots

Not applicable

Testing Procedure

PR Checklist

• [ x] Rebased on top of the target branch at time of PR
• [x ] Changes adhere to coding standard

[mfkl]

Please, no verbose Claude comments.

[mfkl]

so this version will work with the net6-8-9 builds?

[jasells]

The short version, yes, with caveats.

WinUI app projects still on .Net8 or earlier might be forced to bump up to this 1.6.x version, but that's less of a climb than the 1.8.x in main/3.x now. The intent from MS was that any v 1.x should work, with the normal NuGet resolution rules, but Maui9 + win-sdk v1.8 just have an issue that MS didn't catch in QA, and "unsupported" means "they won't fix now." So we're left with having to work around it somewhere. Either in app code suppressions, or in clever version selection here. A lower version would work just as well, from what I can tell, if you're worried about pushing app-code bases up, but you already pushed them up to 1.8....

As I understand it from looking at this particular project, the dependencies of this LibVLCSharp.WinUI don't require anything > .net6 (all deps are either .NetCore5 or .NetStandard), so could simplify this project by only declaring that single target - .Net6. libVlcSharp.Maui can still consume it, as well as any newer native WinUI project. The win-sdk version is your choice, depending on your philosophy as a lib-publisher: push consumers, or declare a floor and let consumers upgrade at their own pace. There aren't any #if net8/9/10 compile directives in the code, so I'd be shocked if the .dll's output from this project for the different targets are actually diff (probably just built once and copied). Would be interesting to check... But I chose these different versions to try and follow the current repo convention of multi-targets, and avoid the issue.

The targets and dependencies are just the "minimum-reqs". A consuming app's target ultimately decides .Net8/9/10/11 even if some of the libs it pulls declare .Net6, the linker can still link them to anything newer. So no "vulnerability" gets transferred from this lib to an app.

If it were my repo, I'd squash the whole tree starting at libVlcSharp.Maui to .Net8 only, maybe keep a separate .Net6 target on this libVlcSharp.WinUI project, if i know/suspect I have consumers still on 6. Seems unlikely at this point, and they could still use an older libVlcSharp.WinUI version that works for their legacy code. But .Net8 alone would support anything 6 years old or newer.

.Net6/8 multi-target here isn't super complicated, just have to add a step in the CI build to add an older sdk's like .Net9 (9 can still build 8 targets), but probably .Net8 SDK would be simplest to install and build both 6+8, if you remove the .Net10 target?

Way easier than continuously chasing the .Net tooling release cycle while still maintaining a wide consumer base.

Here's a CI i have that installs .Net9+8 sdk to ensure I can build .net7-9 target projects still in that repo/sub-repos. Remember: .Net10 is now the default, which is why .Net8-only target projects started failing in CI builds once that was pushed to the agent images. Doesn't require adding .Net10 targets to all code, just install the older .Net-SDK that was the default when it worked.

https://xdevapps.visualstudio.com/Android%20bindings/_build/results?buildId=1428&view=logs&s=96ac2280-8cb4-5df5-99de-dd2da759617d