Labsco
microsoft logo

winapp-package

✓ Official1,100

by microsoft · part of microsoft/winappcli

Package a Windows app as an MSIX installer for distribution or testing. Use when creating a Windows installer, packaging an…

🔥🔥🔥🔥✓ VerifiedFreeQuick setup
🧰 Not standalone. This skill ships with microsoft/winappcli and only works together with that tool — install the tool first, then add this skill.

This is the playbook your agent receives when the skill activates — you don't need to read it to use the skill, but it's here to audit before installing.


name: winapp-package description: Package a Windows app as an MSIX installer for distribution or testing. Use when creating a Windows installer, packaging an Electron/Flutter/.NET/Rust/C++/Tauri app for Windows, building an MSIX, distributing a desktop app, packaging a console app or CLI tool, or adding MSIX packaging to a build script or CI/CD pipeline. version: 0.4.1

When to use

Use this skill when:

  • Creating an MSIX installer from a built app for distribution or testing
  • Packaging any Windows app — GUI apps, console apps, CLI tools, services, or background processes
  • Signing a package with a development or production certificate
  • Bundling the Windows App SDK runtime for self-contained deployment

What the command does

  1. Locates Package.appxmanifest — looks in input folder, then current directory (or uses --manifest)
  2. Copies manifest + assets into a staging layout alongside your app files
  3. Discovers manifest-referenced files — any non-image file referenced in the manifest (e.g., AppExtension payloads like manifest.json, config files) is automatically copied from the manifest directory or input folder if missing from staging
  4. Generates resources.pri — Package Resource Index for UWP-style resource lookup (skip with --skip-pri)
  5. Runs makeappx pack — creates the .msix package file
  6. Signs the package (if --cert provided) — calls signtool with your certificate

Output: a .msix file that can be installed on Windows via double-click or Add-AppxPackage.

Recommended workflow

  1. Build your app (dotnet build, cmake --build, npm run make, etc.)
  2. Packagewinapp package <build-output> --cert ./devcert.pfx
  3. Trust cert (first time) — winapp cert install ./devcert.pfx (admin)
  4. Install — double-click the .msix or Add-AppxPackage ./myapp.msix
  5. Test the installed app from the Start menu

Advanced: External content catalog

For sparse packages with AllowExternalContent, you may need a code integrity catalog:

# Generate CodeIntegrityExternal.cat for external executables
winapp create-external-catalog "./bin/Release"

# Include subdirectories and specify output path
winapp create-external-catalog "./bin/Release" --recursive --output ./catalog/CodeIntegrityExternal.cat

Bundling multiple architectures

Create an MSIX bundle from multiple per-architecture build outputs:

# Create unsigned bundle for Store submission (x64 + arm64)
winapp package ./publish/x64 ./publish/arm64

# Create signed bundle for sideloading
winapp package ./publish/x64 ./publish/arm64 --cert ./devcert.pfx

# Self-contained bundle with Windows App SDK runtime per arch
winapp package ./publish/x64 ./publish/arm64 --self-contained --generate-cert

How it works: When multiple input folders are passed, winapp package:

  1. Detects the architecture of each folder's primary executable from its PE header
  2. Resolves a manifest for each slice (see below)
  3. Validates that all slices share the same Identity, Capabilities, and Dependencies
  4. Packs each folder into an intermediate unsigned .msix
  5. Bundles them into a single .msixbundle using makeappx bundle
  6. Signs only the bundle (not individual slices) — the signature covers all packages inside

Manifest resolution: Each slice needs a manifest. Resolution order:

  • --manifest <path> uses one manifest for all slices (architecture auto-stamped per folder)
  • Per-folder Package.appxmanifest if present in the input folder
  • Fallback to Package.appxmanifest in the current working directory

The ProcessorArchitecture is always force-set to the detected architecture per-slice. All other Identity fields must be consistent across slices.

Output: <Name>_<Version>_<arch1>_<arch2>.msixbundle (architectures sorted alphabetically).

Store submission: An unsigned bundle is valid for Store upload — Partner Center signs it with your reserved identity certificate. For sideloading, pass --cert or --generate-cert.

This hashes executables in the specified directories so Windows trusts them when running with sparse package identity.

CI/CD

GitHub Actions

Use the microsoft/setup-winapp action to install winapp on GitHub-hosted runners:

- uses: microsoft/setup-winapp@v1

- name: Package
  run: winapp package ./dist --cert ${{ secrets.CERT_PATH }} --cert-password ${{ secrets.CERT_PASSWORD }} --quiet

Tips for CI/CD pipelines:

  • Use --quiet (or -q) to suppress progress output
  • Use --if-exists skip with winapp cert generate to avoid regenerating existing certificates
  • Store your PFX certificate as a repository secret and decode it in CI
  • Use --use-defaults (or --no-prompt) with winapp init to avoid interactive prompts

Tips

  • The package command aliases to pack — both work identically
  • Package.appxmanifest Publisher must match the certificate publisher — use winapp cert generate --manifest to ensure they match
  • Use --skip-pri if your app doesn't use Windows resource loading (e.g., most Electron/Rust/C++ apps without UWP resources)
  • For framework-specific packaging paths (Electron, .NET, Rust, etc.), see the winapp-frameworks skill
  • The --executable flag overrides the entry point in the manifest — useful when your exe name differs from what's in Package.appxmanifest
  • For production distribution, use a certificate from a trusted CA and add --timestamp when signing with winapp sign

Related skills

  • Need a manifest first? See winapp-manifest to generate Package.appxmanifest
  • Need a certificate? See winapp-signing for certificate generation and management
  • Having issues? See winapp-troubleshoot for a command selection flowchart and error solutions

Command Reference

winapp package

Create MSIX installer from your built app. Run after building your app. A manifest (Package.appxmanifest or appxmanifest.xml) is required for packaging - it must be in current working directory, passed as --manifest or be in the input folder. Use --cert devcert.pfx to sign for testing. Example: winapp package ./dist --manifest Package.appxmanifest --cert ./devcert.pfx

Aliases: pack

Arguments

<!-- auto-generated from cli-schema.json -->
ArgumentRequiredDescription
<input-folder>YesOne or more input folders with package layout. Pass multiple folders to create an MSIX bundle (e.g., winapp pack ./publish/x64 ./publish/arm64).

Options

<!-- auto-generated from cli-schema.json -->
OptionDescriptionDefault
--certPath to signing certificate (will auto-sign if provided)(none)
--cert-passwordCertificate password (default: password)password
--executablePath to the executable relative to the input folder.(none)
--generate-certGenerate a new development certificate(none)
--install-certInstall certificate to machine(none)
--manifestPath to AppX manifest file (default: auto-detect from input folder or current directory)(none)
--namePackage name (default: from manifest)(none)
--outputOutput file name for the generated package (.msix) or bundle (.msixbundle). Defaults to <name><version><arch>.msix for single packages, or <name><version><arch1>_<arch2>.msixbundle for bundles.(none)
--publisherPublisher distinguished name (DN) for certificate generation (e.g., CN=MyCompany). Bare names are auto-wrapped as CN=<name>.(none)
--self-containedBundle Windows App SDK runtime for self-contained deployment(none)
--skip-priSkip PRI file generation(none)

winapp create-external-catalog

Generates a CodeIntegrityExternal.cat catalog file with hashes of executable files from specified directories. Used with the TrustedLaunch flag in MSIX sparse package manifests (AllowExternalContent) to allow execution of external files not included in the package.

Arguments

<!-- auto-generated from cli-schema.json -->
ArgumentRequiredDescription
<input-folder>YesList of input folders with executable files to process (separated by semicolons)

Options

<!-- auto-generated from cli-schema.json -->
OptionDescriptionDefault
--compute-flat-hashesInclude flat hashes when generating the catalog(none)
--if-existsBehavior when output file already existsError
--outputOutput catalog file path. If not specified, the default CodeIntegrityExternal.cat name is used.(none)
--recursiveInclude files from subdirectories(none)
--use-page-hashesInclude page hashes when generating the catalog(none)