[bug] two MSI installers (multiple WiX languages) collapse into one key in latest.json

Aperta
  • Qualcosa non va?
#3,777 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 3 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
github-actions, rust
Ambito
backend, release

Direzione di ricerca

Find the updater plugin code that assembles latest.json entries for Windows bundle artifacts, then trace how MSI filenames and architectures become manifest keys. Compare the generated keys for a build with wix.language set to en-US and ru-RU. Done means both MSI languages can be selected distinctly, or the build reports the documented limitation without silently overwriting an entry.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

platform: windows plugin: updater type: bug type: feature request
Describe the bug

When bundle.windows.wix.language lists more than one language, both MSIs are built and
attached to the release correctly, but the updater manifest ends up with only one MSI entry
per architecture. The second language overwrites the first.

I build a Tauri v2 app (tauri 2.12.5, tauri-cli 2.12.4, tauri-plugin-updater 2.14.1) for
Windows, Linux and macOS in one GitHub Actions workflow. Each platform job runs
tauri build and the three resulting latest.json files are merged into one, so I can see
exactly which keys each platform produced.

The Windows job produced this:

windows-x86_64       -> StackerPulse_3.2.1_x64_en-US.msi
windows-x86_64-msi   -> StackerPulse_3.2.1_x64_ru-RU.msi
windows-x86_64-nsis  -> StackerPulse_3.2.1_x64-setup.exe

Both MSIs exist and are signed. There is no key that distinguishes them by language, so
windows-x86_64-msi holds the ru-RU build while windows-x86_64 holds the en-US one — two
keys for the same architecture pointing at different languages, and no way to ask for a
specific one.

Reproduction

Real case with both installers and the manifest attached:
https://github.com/UBro-dev/stacker-pulse/releases/tag/v3.2.1

Steps:

  1. Tauri v2 app with msi in bundle.targets:

    "bundle": {
  "targets": ["deb", "appimage", "msi", "nsis", "app"],
  "windows": {
    "wix": { "language": ["en-US", "ru-RU"] },
    "nsis": { "languages": ["English", "Russian"], "displayLanguageSelector": false }
  }
}

  2. Enable the updater and build on Windows.

  3. Inspect the generated latest.json: there is one windows-x86_64-msi key, and it points
    at whichever MSI was processed last — in my case ru-RU — while windows-x86_64 points at
    the en-US MSI.

Both MSIs are built and uploaded, so this is not a bundling failure.

Expected behavior

One of:

  • a distinct key per language, e.g. windows-x86_64-msi-en-US and windows-x86_64-msi-ru-RU,
    so a client can request the right build; or
  • if multiple MSI languages cannot be expressed in the manifest, a warning at build time and
    a documented rule for which one wins, instead of silently replacing the previous entry.

Right now the manifest is correct enough to pass any asset check — all files are present and
signed — while still directing some users to the wrong-language installer.

Full tauri info output
[✔] Environment
    - OS: Windows 10.0.26200 x86_64 (X64)
    ✔ WebView2: 157.0.4341.42
    ✔ MSVC:
        - Visual Studio Build Tools 2022
        - Visual Studio Build Tools 2026
    ✔ rustc: 1.97.1 (8bab26f4f 2026-07-14)
    ✔ cargo: 1.97.1 (c980f4866 2026-06-30)
    ✔ rustup: 1.29.0 (28d1352db 2026-03-05)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 24.19.0
    - npm: 11.17.0
    - bun: 1.4.4

[-] Packages
    - tauri 🦀: 2.12.5
    - tauri-build 🦀: 2.7.4
    - wry 🦀: 0.57.1
    - tao 🦀: 0.37.2

[-] Plugins
    - tauri-plugin-updater 🦀: 2.14.1

[-] App
    - build-type: bundle
    - CSP: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src ipc: http://ipc.localhost; object-src 'none'; base-uri 'none'; form-action 'none'; frame-ancestors 'none'
    - frontendDist: ../ui
Stack trace
N/A — the build succeeds; the problem is in the generated updater manifest.
Additional context

Two side notes that may help narrow it down:

  1. The collision only involves MSI. NSIS has its own single key (windows-x86_64-nsis) and
    the .exe embeds the language selector, so nothing is lost there. The problem is specific
    to producing two MSI files for one architecture.

  2. This is easy to miss in CI. My workflow verifies that every platform has a signed entry in
    latest.json and that all links are pinned to the tag — that check passes, because the
    entries exist. Only comparing the MSI keys against the MSIs actually attached reveals it.
    A user on an MSI install would silently receive the other language after an update.

Previously I filed tauri-apps/tauri#16460 about universal macOS builds with more than one [[bin]]; this is a
separate issue found while verifying the 3.2.1 release.

Lingua principale
Rust
Stelle
1.8k
Fork
637
Merge medio
5g 3h
PR unite (30g)
36

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di tauri-apps/plugins-workspace

Tutte le issue di tauri-apps/plugins-workspace

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.