Auto-update

Once a product is installed, its new versions have to reach the computers it is on. Cobalt Installer puts a small Update.exe beside the program. It reads a file each build writes, sees there is a newer version, shows what is new in it, downloads it, checks that it is exactly the file you published and that it is signed by you, and installs it over the old one with the same answers. You only put two files on your site.

How it works

1. The build writes Product.updates.json beside the setup: the version, the setup's file name, its size and SHA-256, the date, and what is new. The versions the last file had are kept in it.
2. You publish the setup and the updates file in one folder on your site, or as files of a GitHub release.
3. Update.exe — a copy of the installer's engine in the install folder, about 620 KB — reads the updates file: on a schedule, when your program asks, or when the user picks Check for updates in Start.
4. When there is a newer version for this computer, it shows what is new, downloads the setup (going on where a broken download stopped), checks it, and runs it.
5. The new setup updates by the rules of Version upgrades: the same folder and answers, the program closed while its files are replaced and opened again after.

The section is under Release, in Add a feature. Turn on Look for new versions on the users' computers; everything else has a value to start with.

Where the updates are

On a site, put the setup and the updates file in the same folder; a second address can be given, asked when the first does not answer. On GitHub, add both files to each release: GitHub gives the latest release's files at one address that never changes, so no server of your own is needed.

Only https. Over http anyone on the way — a café's Wi-Fi, a proxy — could hand out another file. For a try on your own computer, http://127.0.0.1:… and http://localhost:… are taken too.

The addresses take the project's values: https://example.com/{ProductName}/.

The updates file

{
  "product": "Tiny App",
  "id": "{6F1C2A7E-…}",
  "publisher": "Cobaltsmith",
  "versions": [
    {
      "version": "1.1.0",
      "channel": "stable",
      "date": "2026-11-10",
      "file": "TinyApp-1.1.0-Setup.exe",
      "size": 1570608,
      "sha256": "d918f79c…",
      "critical": false,
      "rollout": 100,
      "notes": { "en": "- Batch rename by a pattern\n- JPEG XL and AVIF" }
    }
  ]
}

The file can be changed by hand after the build: to stop a version found to be wrong (rollout lowered, or the entry taken out), or to mark it critical.

What is new

From the changelog, or written in the section. A changelog is read by its headings: the part of version 1.4.0 goes from a heading with it — ## 1.4.0, ## [1.4.0] - 2026-11-10, ### v1.4 — to the next heading as high. The file chosen is in the installer's default language; CHANGELOG.de.md beside it gives the German text, and so on. Lists, headings and bold are shown as plain lines.

When the changelog has no part for the version being built, Problems says so.

When it looks

The schedule has what Task Scheduler has:

Then the time, by the computer's clock, and a spread — none, 15 minutes, an hour, four hours — over which each computer's time falls at random, so a thousand of them don't come to your server in the same minute. A time missed while the computer was off comes as soon as it is on. At the user's sign-in too adds a look two minutes after each sign-in. Under the schedule the editor shows its next three times — the same Windows will keep.

Why the schedule is off by default

A task that starts a program at sign-in or at set times is also how malware keeps itself on a computer. Microsoft Defender judges such a task by who signed the program: while the setup is unsigned, or signed by a certificate Windows does not trust (one made by yourself), it is likely to put Update.exe in quarantine and delete the task. With a code signing certificate from a known authority this does not happen. Until then, let your program run Update.exe --check --background as it starts: nothing stays on the computer to look like that.

What it does with a new version

This version — said of the version being built, in the updates file:

• Critical: it can't be put off or skipped — a security fix, a server that changed.
• Offered first to 10%, 25%, 50% or all of the computers. Each computer's place among them stays the same for the version, so the first 10% are the same computers each time it is looked at. Found a problem — lower it, or take the version out of the updates file, and the rest won't get it.

The check

What is downloaded is installed only if all of this holds:

1. Its size and SHA-256 are those in the updates file.
2. It is signed by the same publisher as Update.exe itself. The same publisher, not the same certificate: certificates are renewed every year, the company's name stays.
3. Windows trusts the signature, revoked certificates included.

It can't be turned off. While the setup is not signed, only the SHA-256 is checked — and a setup changed on the server together with the updates file would go through; Problems says so.

Administrators and your program

// C#: Help → Check for updates
var update = Path.Combine(AppContext.BaseDirectory, "Update.exe");
Process.Start(update, "--check");

Update.exe writes what it did to %TEMP%\Product Update.log.