release-velopack: publish reuses the gates' obj and ships a stale resource index; add a launch smoke test #22

New Issue

2026-10-10T17:47:50Z

KofTwentyTwo commented

2026-10-10 17:47:50 +00:00

(Migrated from github.com)

Found by KofTwentyTwo/gclo#87: gclo v1.0.1, the first stable release built by release-velopack.yml@e8ab30f, passed every gate and crashed at startup (0xc000027b in Microsoft.UI.Xaml.dll).

Cause. The workflow runs dotnet build <solution> -c Release -p:Platform=<platform> (framework-dependent Windows App SDK) and then dotnet publish <app> … -p:WindowsAppSDKSelfContained=true into the same obj. The app's resource index (<app>.pri) is generated incrementally by _GenerateProjectPriFileCore (Inputs: referenced .pri files, Output: the index). The publish adds the Windows App SDK resource files as inputs, but they are older (NuGet cache timestamps) than the index the build already wrote, so MSBuild skips the target and the published app ships a framework-dependent index without the WinUI theme resources. Reproduced from clean with the workflow's commands; publish alone produces the correct index.

Suggestions for the shared workflow

Do not let the publish inherit the gates' obj: publish after dotnet clean/removing obj of the app project, or build and publish with the same WindowsAppSDKSelfContained/WindowsPackageType values (gclo now fixes both in its csproj as a belt-and-braces measure).
Add a smoke step between publish and the draft release: start publish/app/<main-exe> and fail unless the process is still alive after N seconds (or, if the caller supplies a test project, run it with the published exe). gclo now runs its FlaUI suite against the published exe in a caller-side smoke job that gates release, but the step belongs in the shared workflow so every consumer gets it.
The rehearsal guidance in standards/releases.md should say that a prerelease rehearsal counts only once the installer has been run on a clean machine.

gclo's fix: KofTwentyTwo/gclo#87.

Found by KofTwentyTwo/gclo#87: gclo v1.0.1, the first stable release built by `release-velopack.yml@e8ab30f`, passed every gate and crashed at startup (`0xc000027b` in `Microsoft.UI.Xaml.dll`). **Cause.** The workflow runs `dotnet build <solution> -c Release -p:Platform=<platform>` (framework-dependent Windows App SDK) and then `dotnet publish <app> … -p:WindowsAppSDKSelfContained=true` into the **same `obj`**. The app's resource index (`<app>.pri`) is generated incrementally by `_GenerateProjectPriFileCore` (Inputs: referenced `.pri` files, Output: the index). The publish adds the Windows App SDK resource files as inputs, but they are older (NuGet cache timestamps) than the index the build already wrote, so MSBuild skips the target and the published app ships a framework-dependent index without the WinUI theme resources. Reproduced from clean with the workflow's commands; publish alone produces the correct index. **Suggestions for the shared workflow** 1. Do not let the publish inherit the gates' `obj`: publish after `dotnet clean`/removing `obj` of the app project, or build and publish with the same `WindowsAppSDKSelfContained`/`WindowsPackageType` values (gclo now fixes both in its csproj as a belt-and-braces measure). 2. Add a smoke step between publish and the draft release: start `publish/app/<main-exe>` and fail unless the process is still alive after N seconds (or, if the caller supplies a test project, run it with the published exe). gclo now runs its FlaUI suite against the published exe in a caller-side `smoke` job that gates `release`, but the step belongs in the shared workflow so every consumer gets it. 3. The rehearsal guidance in `standards/releases.md` should say that a prerelease rehearsal counts only once the installer has been run on a clean machine. gclo's fix: KofTwentyTwo/gclo#87.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: KofTwentyTwo/standards#22