Skip to content

Bundle the sherpa runtime DLLs in the Windows installer - #103

Merged
ppXD merged 2 commits into
mainfrom
windows-bundle-dlls
May 30, 2026
Merged

ppXD merged 2 commits into
mainfrom
windows-bundle-dlls

Conversation

@ppXD

@ppXD ppXD commented May 30, 2026

Copy link
Copy Markdown
Owner

Summary

  • The Windows .msi/.exe shipped only app.exe — none of onnxruntime.dll, sherpa-onnx-c-api.dll, cargs.dll, or onnxruntime_providers_shared.dll. Because app.exe statically imports sherpa-onnx-c-api.dll, the installed app can't launch at all (missing-DLL error before main). Verified by 7z-listing the built installer: only app.exe + NSIS's own plugin DLLs were inside.
  • sherpa-rs-sys copies those DLLs to target/release at build time. A platform-specific tauri.windows.conf.json (Tauri auto-merges it on Windows builds) bundles them next to the executable — the counterpart to the existing bundle.macOS.frameworks. macOS/Linux configs are untouched.

Test plan

  • Re-run release.yml on this branch; 7z l the wisp-windows-x64 artifact and confirm onnxruntime.dll, sherpa-onnx-c-api.dll, cargs.dll, onnxruntime_providers_shared.dll, and resources/silero_vad.onnx are all present.
  • CI app builds (windows) stays green (config change only; doesn't affect cargo build).
  • Manual (Windows hardware): install, launch, download a model, transcribe — no missing-DLL error.

ppXD added 2 commits May 31, 2026 07:21
The Windows .msi/.exe shipped only app.exe — none of onnxruntime.dll,
sherpa-onnx-c-api.dll, cargs.dll, or onnxruntime_providers_shared.dll.
Since app.exe statically imports sherpa-onnx-c-api.dll, Windows can't
even launch it: the installed app dies immediately with a missing-DLL
error, so no model ever loads. (CI only ran `cargo build` and the
release job only checked that the bundle was produced, so the gap was
invisible until an install was inspected.)

sherpa-rs-sys copies those DLLs to target/release at build time. Bundle
them next to the executable via a platform-specific tauri.windows.conf
(Tauri auto-merges it on Windows builds) — the counterpart to the
existing bundle.macOS.frameworks that ships the dylibs on macOS.
tauri-build validates `resources` paths at compile time, so pointing the
bundle config straight at `target/release` broke `cargo build` (debug)
and would break `tauri dev` on Windows — the path only exists in a
release build. Stage the four sherpa/onnxruntime DLLs from the cargo
target dir into a fixed, gitignored `windows-runtime/` in build.rs (the
counterpart to the macOS rpath block already there) and point the
resources at that profile-independent location instead.
@ppXD
ppXD merged commit c442230 into main May 30, 2026
6 checks passed
@ppXD
ppXD deleted the windows-bundle-dlls branch May 30, 2026 23:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant