v1.0.1 crashes at startup (0xc000027b): published gclo.pri lacks the WinUI resources #87

New Issue

2026-10-10T17:45:59Z

KofTwentyTwo commented

2026-10-10 17:45:59 +00:00

(Migrated from github.com)

v1.0.1 (and the v1.0.1-beta.3 rehearsal) crash at startup with 0xc000027b in Microsoft.UI.Xaml.dll, before any window or log line. A 1.0.0 install that auto-updated is left unable to start.

Root cause

The published app's resource index gclo.pri is 115,816 bytes instead of ~2.3 MB: it lacks the WinUI theme resources (generic.xbf, themeresources.xbf, Compact.xbf …) that a self-contained unpackaged app must carry in its own index. XAML cannot resolve generic.xaml and fails fast.

The index is generated incrementally in obj by _GenerateProjectPriFileCore (Inputs: the referenced .pri files; Output: gclo.pri). The shared release workflow first runs dotnet build gclo.slnx -c Release -p:Platform=x64 (framework-dependent: the Windows App SDK resources are not inputs), then dotnet publish … -p:WindowsAppSDKSelfContained=true into the same obj\x64\Release\…\win-x64. The publish adds Microsoft.UI.Xaml.Controls.pri etc. as inputs, but those files (from the NuGet cache) are older than the already-written gclo.pri, so MSBuild treats the target as up to date and the stale index ships.

Reproduced locally from clean bin/obj with the exact workflow commands (115,816 bytes, crash); publish alone, or a Debug build followed by the publish (what the 1.0.0 workflow did), give 2,298,032 bytes and a working app. A warm obj masks it, which is why the local checks before #77/#79 passed.

Fix

gclo.csproj: WindowsPackageType=None and WindowsAppSDKSelfContained=true unconditionally. gclo ships only unpackaged and self-contained, so build and publish now share one resource configuration and the incremental index is always the right one.
release.yml: a smoke job between gates and release that publishes with the shared workflow's exact command and runs the FlaUI suite against the published exe (GCLO_UITEST_EXE). The release job needs it, so a non-starting build can never be published again.
docs/RELEASING.md "A broken release" applied to v1.0.1 (notes edited, marked prerelease so stable installs stop receiving it); ship v1.0.2.
Standards follow-up: the shared release-velopack.yml publishes into the obj of its earlier Release build; filed separately.

Part of #62.

**v1.0.1 (and the v1.0.1-beta.3 rehearsal) crash at startup** with `0xc000027b` in `Microsoft.UI.Xaml.dll`, before any window or log line. A 1.0.0 install that auto-updated is left unable to start. ## Root cause The published app's resource index `gclo.pri` is 115,816 bytes instead of ~2.3 MB: it lacks the WinUI theme resources (`generic.xbf`, `themeresources.xbf`, `Compact.xbf` …) that a **self-contained** unpackaged app must carry in its own index. XAML cannot resolve `generic.xaml` and fails fast. The index is generated incrementally in `obj` by `_GenerateProjectPriFileCore` (Inputs: the referenced `.pri` files; Output: `gclo.pri`). The shared release workflow first runs `dotnet build gclo.slnx -c Release -p:Platform=x64` (framework-dependent: the Windows App SDK resources are not inputs), then `dotnet publish … -p:WindowsAppSDKSelfContained=true` into the same `obj\x64\Release\…\win-x64`. The publish adds `Microsoft.UI.Xaml.Controls.pri` etc. as inputs, but those files (from the NuGet cache) are older than the already-written `gclo.pri`, so MSBuild treats the target as up to date and the stale index ships. Reproduced locally from clean `bin`/`obj` with the exact workflow commands (115,816 bytes, crash); publish alone, or a Debug build followed by the publish (what the 1.0.0 workflow did), give 2,298,032 bytes and a working app. A warm `obj` masks it, which is why the local checks before #77/#79 passed. ## Fix - `gclo.csproj`: `WindowsPackageType=None` and `WindowsAppSDKSelfContained=true` unconditionally. gclo ships only unpackaged and self-contained, so build and publish now share one resource configuration and the incremental index is always the right one. - `release.yml`: a `smoke` job between `gates` and `release` that publishes with the shared workflow's exact command and runs the FlaUI suite against the published exe (`GCLO_UITEST_EXE`). The release job needs it, so a non-starting build can never be published again. - `docs/RELEASING.md` "A broken release" applied to v1.0.1 (notes edited, marked prerelease so stable installs stop receiving it); ship **v1.0.2**. - Standards follow-up: the shared `release-velopack.yml` publishes into the `obj` of its earlier Release build; filed separately. Part of #62.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: KofTwentyTwo/gclo#87