7.0 KiB
Windows desktop build under Wine
The PR workflow uses the existing ubuntu-latest Gitea runner with pinned Wine 11 and a matching Windows .NET SDK. It builds both the application and test project for net10.0-windows10.0.19041.0, then discovers and executes that actual Windows test target through the Windows host. The desktop target retains WPF, WinExe, x64, and the Windows recording, hotkey, Outlook, screenshot, tray, and notification implementations. The separate portable job explicitly selects net10.0; a Windows host or win-x64 RID alone does not compile Windows-only tests.
Observed failures
On 2026-10-03, run 4154 at commit 05e23857ddf9e6990b76660e2ef5c1b429bfe66b used Wine 11 and successfully imported and read back all 372 unique thumbprints from the Microsoft SDK's code-signing and timestamp trust bundles. The Windows SDK targeting-pack diagnostic succeeded, and the Windows desktop restore completed. NuGet signature verification was not disabled. See the trust helper documentation.
The desktop build then failed in WinAppSdkExpandPriContent from Microsoft.Windows.SDK.BuildTools.MSIX 1.7.20250829.1. MakePRI reported PRI175: 0x80004001 - Dump, MakePri failed with error: Not implemented, and PRI222. The following Root element is missing exception came from loading the missing dump output; it was a secondary failure. These logs establish a MakePRI compatibility failure under Wine, but do not identify the particular unimplemented Wine API.
Dependency correction
The resolved Windows graph was:
H.NotifyIcon.Uno.WinUI 2.4.1
-> H.NotifyIcon 2.4.1
-> Microsoft.WindowsAppSDK 1.8.251106002
-> Microsoft.WindowsAppSDK.Base 1.8.250831001
-> Microsoft.Windows.SDK.BuildTools.MSIX 1.7.20250829.1
UnoTaskbarIconService.Windows.cs uses H.NotifyIcon.Core.TrayIconWithContextMenu, PopupMenu, PopupMenuItem, PopupMenuSeparator, and PopupSubMenu. These types come from the already-selected H.NotifyIcon 2.4.1 assembly. The application does not use the wrapper's WinUI/Uno XAML controls. The Windows package reference therefore selects H.NotifyIcon 2.4.1 directly. This keeps the same core assembly and tray APIs while removing the unused WinUI wrapper and its Windows App SDK graph. CommunityToolkit.WinUI.Notifications 7.1.2 remains available for toast notifications and does not introduce Windows App SDK in the selected Windows target.
The package author's core-package documentation supports using H.NotifyIcon directly, including in console applications. Its net10.0 dependency group contains H.GeneratedIcons.System.Drawing 2.4.1. The wrapper package adds Windows App SDK for its Windows target.
PRI expansion discovers referenced asset files that are absent from normal project outputs and adds them to copy-local output. Disabling that target would risk losing real WinUI resource payloads. This correction removes an unused application dependency instead of disabling PRI generation/expansion, creating a dummy PRI file, suppressing signature checks, or changing the desktop target.
Qualification and remaining CI evidence
Local qualification on 2026-10-03 used the existing mcr.microsoft.com/dotnet/sdk:10.0-noble container image with SDK 10.0.401. The existing NuGet package cache was a read-only fallback; new package/cache writes went to a separate temporary directory. This command inside the container compiled the complete Windows desktop target:
dotnet build MeetingAssistant/MeetingAssistant.csproj \
-c Release -f net10.0-windows10.0.19041.0 -r win-x64 \
-p:EnableWindowsTargeting=true -p:RestoreFallbackFolders=/host-nuget --nologo
The command returned zero with Build succeeded, zero errors, and four existing NAudio deprecation warnings. The produced runtime configuration retains Microsoft.WindowsDesktop.App alongside the .NET and ASP.NET frameworks. The regenerated assets graph contains H.NotifyIcon/2.4.1, no Microsoft.WindowsAppSDK* packages, and no Microsoft.Windows.SDK.BuildTools.MSIX; generated package imports contain no Windows App SDK or MakePRI entry. The output H.NotifyIcon.dll is byte-identical to the previously selected cached core assembly, with SHA-256 0027e443a6121af8fb616c0200d3c63bf4abb72e3c548e119fee1eae321a8368. No application source or target suppression was required. This Linux cross-build does not establish that Windows dotnet.exe succeeds under Wine.
Completion requires a new Gitea run at the tested revision: successful full Windows desktop and test builds under Wine, named Windows discovery, actual assertion execution with a fresh artifacts/tests/windows/windows.trx, and a passing evidence verifier. The workflow removes the previous application DLL/TRX at the expected paths and requires nonempty replacements. All five existing Outlook cases and the Windows-only environment/glyph checks must pass; native macOS tests report their explicit platform skip outside macOS. Windows-target test execution does not establish real Outlook COM, hardware or tray/UI operation.
After the workflow installs the Windows SDK and provisions its Wine trust store, its validation commands use the Windows TFM throughout:
set -euo pipefail
mkdir -p artifacts/tests/windows
"${WINE_BIN}" "${WIN_DOTNET_DIR}/dotnet.exe" restore MeetingAssistant.Tests/MeetingAssistant.Tests.csproj \
-p:TargetFramework=net10.0-windows10.0.19041.0 -p:EnableWindowsTargeting=true -r win-x64
"${WINE_BIN}" "${WIN_DOTNET_DIR}/dotnet.exe" build MeetingAssistant/MeetingAssistant.csproj \
-c Release -f net10.0-windows10.0.19041.0 -r win-x64 -p:EnableWindowsTargeting=true
"${WINE_BIN}" "${WIN_DOTNET_DIR}/dotnet.exe" build MeetingAssistant.Tests/MeetingAssistant.Tests.csproj \
-c Release -f net10.0-windows10.0.19041.0 -r win-x64 --no-restore -p:EnableWindowsTargeting=true
"${WINE_BIN}" "${WIN_DOTNET_DIR}/dotnet.exe" test MeetingAssistant.Tests/MeetingAssistant.Tests.csproj \
-c Release -f net10.0-windows10.0.19041.0 -r win-x64 --no-build --list-tests \
> artifacts/tests/windows/discovery.txt
rm -f artifacts/tests/windows/windows.trx
"${WINE_BIN}" "${WIN_DOTNET_DIR}/dotnet.exe" test MeetingAssistant.Tests/MeetingAssistant.Tests.csproj \
-c Release -f net10.0-windows10.0.19041.0 -r win-x64 --no-build \
--logger 'trx;LogFileName=windows.trx' --results-directory artifacts/tests/windows
dotnet run tools/VerifyPlatformTests.cs -- windows \
artifacts/tests/windows/discovery.txt artifacts/tests/windows/windows.trx
The checked-in workflow additionally records the commit, both SDK identities, Wine version, trust import/readback and targeting-pack diagnostics, plus separate build, discovery, execution and verification logs. It uploads available Windows evidence even after a failed step; the portable job retains its own evidence separately. See platform test verification for native Windows/portable commands and acceptance limits. No required PRI/resource target is disabled.