Type an appId and see the exact Windows installer identity that electron-builder's
NSIS target derives from it: the GUID, the uninstall and install registry keys, and the single-installer mutex.
Everything is computed in this page. There is no network request of any kind.
Behaviour reimplemented from app-builder-lib 26.15.3. Source read 2026-09-05.
appId string alone. Two builds that agree on product name, publisher, version and file layout
but differ in appId write different uninstall registry keys, so the new installer does not find
the old install and does not upgrade it. The install directory, by contrast, is derived from entirely
different fields, so it can stay identical while the identity underneath it changes.
| NSIS define | Value | Derived from |
|---|
nsis.guid explicitly bypasses the derivation entirely. The NSIS target reads
options.guid first and only falls through to the UUID v5 derivation when it is absent. If you
set it, every GUID row below is irrelevant to your build.APP_FILENAME, PRODUCT_FILENAME and the updater cache directory are
not derived from appId. They come from name,
productName and executableName. Only the GUID, the uninstall key,
the install registry key and the installer mutex trace back to appId.UNINSTALL_REGISTRY_KEY_2, is emitted only when the uninstall
app key differs from the GUID. That happens only for a hand-set nsis.guid containing a
backslash, because a derived v5 GUID is hexadecimal and hyphens and can never contain one. It is
omitted from the table above for that reason.The derivation is only worth reading if the primitives underneath it are right. This runs published SHA-1 test vectors, known UUID v5 pairs, filename sanitisation cases, and one positive control that must always fail. A checker that has never produced a failure has not been tested.