microsoft / microsoft/winget-cli

WinGetSourceCreator: PackWithMappingFile should verify makeappx.exe exists before invoking it

Open Beginner friendly
#6,427 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Issue-Feature
Dominant language
C++
Stars
26.4k
Forks
1.8k
Avg merge
1d 11h
Merged PRs (30d)
15

Description

Prerequisite: #6426 / #4181 must be fixed first

This fix depends on
#6426 (re-file of
#4181). Today
CopyManifestFile fails to create destination subdirectories, so the
IndexCreationTool / WinGetSourceCreator path breaks before it ever reaches
index creation - the tool cannot be used at all for anything laid out in
subfolders (which includes every real multi-file manifest).

Both fixes are required for the end-to-end offline-source scenario:

  1. #6426 / #4181 - create destination subdirectories in CopyManifestFile
    (prerequisite; without it the tool is unusable for subfoldered input).

Summary

Helpers.PackWithMappingFile in src/WinGetSourceCreator/Helpers.cs resolves makeappx.exe from the detected Windows SDK bin path and invokes it without verifying the executable exists. When the SDK is missing, incomplete, or the detected bin path is wrong, the failure surfaces as an opaque process-launch error instead of a clear, actionable message — costing significant debugging time when building an offline source package.

The sibling method SignFile already validates its inputs (it throws FileNotFoundException when signature.CertFile is missing). PackWithMappingFile should be consistent and fail fast with a clear message when makeappx.exe is not found.

Why this matters (air-gapped / regulated environments)

Offline source packaging with IndexCreationTool / WinGetSourceCreator is the supported path for air-gapped, heavily regulated environments that cannot use a public REST source. These builds frequently run on hardened/locked-down build agents where the Windows SDK layout cannot be assumed. A precise "makeappx.exe not found at <path>" error turns a confusing failure into a one-line fix (install/point at the SDK), which matters a lot when the environment is deliberately minimal.

Proposed fix

In PackWithMappingFile (src/WinGetSourceCreator/Helpers.cs), add an existence check before running the tool:

string pathToSDK = SDKDetector.Instance.LatestSDKBinPath;
string makeappxExecutable = Path.Combine(pathToSDK, "makeappx.exe");
if (!File.Exists(makeappxExecutable))
{
    throw new FileNotFoundException($"makeappx.exe not found at {makeappxExecutable}");
}
string args = $"pack /o /nv /f \"{mappingFile}\" /p \"{outputPackage}\"";
RunCommand(makeappxExecutable, args);

The same guard could reasonably be applied to the other makeappx.exe / signtool.exe call sites in this file for consistency.

Happy to submit a PR alongside the CopyManifestFile fix (see companion issue).

Environment

  • Windows 10 / 11
  • winget-cli master
  • Component: src/WinGetSourceCreator

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with PackWithMappingFile in src/WinGetSourceCreator/Helpers.cs and review how it resolves and invokes makeappx.exe. Confirm prerequisite issue #6426 is addressed, then verify that a missing executable produces a clear FileNotFoundException and that an existing executable still runs the packaging command.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
cli
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.