Skip to content

fix windows-sdk+maui9 issue #435

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jasells wants to merge 1 commit into
base: 3.x
Choose a base branch
from
Open

fix windows-sdk+maui9 issue #435

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 29 additions & 1 deletion src/LibVLCSharp.WinUI/LibVLCSharp.WinUI.csproj
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,8 +33,36 @@ LibVLC needs to be installed separately, see VideoLAN.LibVLC.Windows.</Descripti
</Page>
</ItemGroup>

<!-- WindowsAppSDK is pinned per target-framework generation so we never force a consumer onto a
WindowsAppSDK newer than its .NET MAUI generation can use. WindowsAppSDK 1.8.x's build targets
copy Microsoft.Maui's HybridWebView.js from a path MAUI 9.0.x does not ship, causing MSB3030 in
consuming MAUI 9.0.x apps (WindowsAppSDK#6032). HybridWebView arrived in MAUI 9, so MAUI 8 lacks
that file too and is likewise exposed to 1.8 - hence every pre-net10 TFM (MAUI <= 9) stays below
1.8.
MAUI pins WindowsAppSDK via its workload and consuming apps only roll it *up* to that floor,
so a pin at/below a generation's floor can never downgrade a consumer. Per Microsoft.Maui.Core's
NuGet dependency: MAUI 8.0.x resolves WindowsAppSDK 1.3.x-1.5.x, MAUI 9.0.x resolves 1.6.x-1.7.x
(and never 1.8). Overriding MAUI's pin is unsupported. Sources:
https://learn.microsoft.com/en-us/answers/questions/5645769/net-maui-compatibility-with-windowsappsdk-1-8 (override unsupported)
https://www.nuget.org/packages/Microsoft.Maui.Core/8.0.3 (WindowsAppSDK >= 1.3.230724000)
https://www.nuget.org/packages/Microsoft.Maui.Core/8.0.100 (WindowsAppSDK >= 1.5.240802000)
https://www.nuget.org/packages/Microsoft.Maui.Core/9.0.0 (WindowsAppSDK >= 1.6.240923002)
https://www.nuget.org/packages/Microsoft.Maui.Core/9.0.120 (WindowsAppSDK >= 1.7.250909003)
https://raw.githubusercontent.com/dotnet/maui/release/9.0.1xx/eng/Versions.props (MicrosoftWindowsAppSDKPackageVersion) -->
<ItemGroup Condition="!$(TargetFramework.StartsWith('net10.0'))">
<PackageReference Include="Microsoft.WindowsAppSDK" Version="1.6.240923002" />

@mfkl mfkl Jul 2, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@jasells jasells Jul 3, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

</ItemGroup>
<!-- net10-windows: pin MAUI 10.0.x's GA floor so consumers roll *up* as needed (e.g. MAUI 10.0.80+
rolls up to 1.8.251106002) rather than being forced higher. MAUI 10.0.0 (GA) floors at
WindowsAppSDK 1.7.250909003. Sources:
https://www.nuget.org/packages/Microsoft.Maui.Core/10.0.0 (WindowsAppSDK >= 1.7.250909003)
https://www.nuget.org/packages/Microsoft.Maui.Core/10.0.80 (WindowsAppSDK >= 1.8.251106002)
https://raw.githubusercontent.com/dotnet/maui/release/10.0.1xx/eng/Versions.props (MicrosoftWindowsAppSDKPackageVersion) -->
<ItemGroup Condition="$(TargetFramework.StartsWith('net10.0'))">
<PackageReference Include="Microsoft.WindowsAppSDK" Version="1.7.250909003" />
</ItemGroup>

<ItemGroup>
<PackageReference Include="Microsoft.WindowsAppSDK" Version="1.8.251106002" />
<PackageReference Include="Microsoft.Windows.SDK.BuildTools" Version="10.0.26100.7175" />
<PackageReference Include="SharpDX.Direct3D11" Version="4.2.0" />
<PackageReference Include="System.Net.Http" Version="4.3.4" NoWarn="NU1510" />
Expand Down