Config files to support silent installation

Relevant area(s)

• WinGet CLI

Description of the new feature / enhancement

Some installers require or support a configuration / answer file to drive a silent or customized installation — content that can't always be expressed as command-line switches. Examples raised over the life of this issue:

• MSI transform files (.mst) — e.g. licensed FortiClient requires an MST to install correctly
• Setup Factory response files (.rsp / config)
• Inno Setup / InstallShield answer files (.iss)
• Oracle client response files (.rsp)

Today a user can only influence the installer command line via --override (replaces the entire argument string) or --custom (appends switches). For switch-based installers this technically allows referencing a file — e.g. winget install <pkg> --override "TRANSFORMS=C:\path\file.mst /qn" — but:

• It requires the user to know the exact vendor-specific switch syntax.
• There's no first-class, discoverable experience.
• It doesn't help installers that expect a config file staged at a known path rather than referenced by a switch.

Proposed scope (intentionally narrow): add a new install-time argument that lets the person running winget install point to a local configuration file they already have, which winget passes through to the underlying installer. The configuration file is supplied by the customer at install time — it is not stored in the winget-pkgs manifest repository. This keeps arbitrary (and potentially sensitive or attacker-controllable) configuration content out of the community repo and puts control in the hands of the installing user or organization.

Proposed technical implementation details

• New argument on winget install (and likely winget upgrade), e.g. --config-file <path> — naming TBD; must not collide with winget configure / DSC "configuration" terminology.
• winget validates the path exists and is readable, then makes it available to the installer via one of:
  • Switch substitution — the manifest declares how the file path maps to the installer's switch (e.g. TRANSFORMS=<file> for MSI) and winget substitutes the user-provided path.
  • File staging — winget places the file where the installer expects it.
• The manifest may optionally declare whether a package supports or requires a configuration file, so winget can prompt or error clearly when one is needed but not provided.
• Define interaction with existing --override / --custom (precedence / mutual exclusivity).

Out of scope / non-goals:

• Storing configuration file contents in winget-pkgs.
• Generating vendor config files from manifest data (the earlier "Design A" alternative — not being pursued here).

Open questions:

• Argument name, to avoid confusion with WinGet Configuration (DSC).
• Should winget hash/validate the file? It's user-provided, so the trust model differs from a downloaded installer.
• Per-installer-type support matrix — MSI TRANSFORMS is the clearest first target.

Updated with GitHub Copilot.

Start with the WinGet CLI install and upgrade command entry points and the installer integration, then review how existing --override and --custom arguments are handled. Define the argument name, manifest contract, file validation or staging behavior, and precedence rules before implementing and testing the MSI TRANSFORMS case.