Windows App Updates
Your Windows app checks a signed update feed hosted at your own URL. SessionCloud produces the release files; you download them from the portal and copy them to your web server or file-sharing service for each release.
For signing and publisher setup, first see Windows Production Requirements.
1. Choose your update folder
Use an HTTPS location that serves the files directly, without a login, browser preview page or expiring share token. A file-sharing service is suitable only if it provides stable direct download URLs with the required filenames. A Windows network path such as \\server\share is not an HTTPS update URL.
For example, enter this in App Store → Windows → Windows Update Url before building:
https://downloads.example.com/softphone/windowsEnter the folder URL without a trailing slash. Do not include winconfig.xml; the build adds that filename. Keep this URL available for the lifetime of installed apps. Changing the portal setting only changes future builds; existing installations still check their original URL.
2. Configure update signing
Set the project’s matching Update Private Key and Update Public Key in App Store before building. The build signs the installer and feed for the updater using this key pair, and the app uses the public key to verify downloads.
These update signatures are separate from Windows publisher/code signing. Keep the private key secret and never upload it to the public update folder. Preserve the same key pair for later releases so installed apps can verify their updates.
3. Copy all three release files
Download the completed Windows build ZIP from the portal and extract it. Copy these three files from the same build into your update folder:
| File | Purpose |
|---|---|
<product>-x64.msi | The signed Windows installer downloaded by the updater. |
winconfig.xml | The feed containing the version, installer URL and installer update signature. |
winconfig.xml.signature | The detached signature used to verify the XML feed. |
For an app named ExamplePhone, the resulting URLs are:
https://downloads.example.com/softphone/windows/ExamplePhone-x64.msi
https://downloads.example.com/softphone/windows/winconfig.xml
https://downloads.example.com/softphone/windows/winconfig.xml.signatureUpload the extracted files, not just the ZIP. Keep their generated filenames. Do not edit or reformat the XML, alter the MSI after signing, or use a signature from a different build: the updater verifies the signed file contents.
4. Publish each new version
- Increase Windows Version to a version higher than the installed release. Incrementing only the build number is not a substitute for a newer version in the update feed.
- Build and test the release, then download and extract its ZIP.
- Upload the new MSI first. Publish
winconfig.xmlandwinconfig.xml.signaturetogether using your host’s staged or atomic publishing feature where available. - If your host cannot publish the files together, upload them consecutively in one release window. A temporary mismatch can make update verification fail until all files are in place.
- Refresh any CDN or hosting caches so the XML, its signature and the MSI all come from the same release.
- Verify an update using a PC with the earlier version installed.
The generated installer filename is reused between releases. Keep a private backup of each complete release and minimise the interval during which hosting contains files from different builds.
Verify your hosting
Open each URL in a private browser window. It should return the actual file without signing in. Confirm that the installer URL inside winconfig.xml points to your hosted MSI and that your host allows the .signature extension.
If an update is not offered, check the feed version and the URL embedded in the installed app. If verification fails, check for stale caches, changed file contents, a mismatched signature or a changed update key. Re-upload the original matching files rather than editing the XML to repair it; rebuild if the configured URL or version is wrong.