NetSparkle: self-hosted app cast updates for .NET desktop apps

An app cast on your server is the contract with your users

NetSparkle is a C# framework that sits between your application and a file you host. You publish an app cast somewhere on the internet, containing update and version information along with release notes in Markdown or HTML format. The library then handles the rest of the flow: it checks whether an update exists, shows the user the release notes, and offers to download and install the new version.

That structure is the whole idea, and it has a practical consequence. There is no update service to sign up for and no account to configure, because the app cast is a document you serve. The cost is that you now own the hosting, the version numbering, the format of the file and the cryptography that proves a download came from you rather than from someone who swapped the URL.

The framework targets .NET Framework 4.6.2 and later as well as .NET 6 and later, which means one codebase can serve an old enterprise desktop estate and a modern one. It is described as highly configurable, and it permits a custom UI or no built-in UI at all, so the update check is usable as a library call even in a service with no window.

Picking between the core package and the built-in UIs

The NuGet packages are split by how much of the interface you want. The core package NetSparkleUpdater.SparkleUpdater is for teams who do not want a built-in UI and can manage the flow themselves. Each other package adds a ready-made window for one UI framework.

There is a wrinkle in the table that matters for anyone still on the older runtime. WinForms ships as two packages, one for .NET Framework and one for .NET 6+, named NetSparkleUpdater.UI.WinForms.NetFramework and NetSparkleUpdater.UI.WinForms.NetCore. WPF is a single package covering both .NET Framework and .NET 6+. Avalonia has its own package, NetSparkleUpdater.UI.Avalonia, which matters because Avalonia is the route to a cross-platform desktop application with one UI code base.

Two command line tools round out the set. NetSparkleUpdater.Tools.AppCastGenerator ships the netsparkle-generate-appcast tool with Ed25519 helpers, and NetSparkleUpdater.Tools.DSAHelper ships the netsparkle-dsa tool for DSA signatures. The installation note in the README gives the App Cast Generator install as:

dotnet tool install --global NetSparkleUpdater.Tools.AppCastGenerator

Because the signing helpers live in the generator tool rather than in the runtime library, generating a signed app cast is a build step you run on a machine that holds the key.

Ed25519 signatures and the DSA helper as an alternative

Signing is where an update mechanism earns trust, and NetSparkle supports Ed25519 or other cryptographic signatures on the app cast. That means the client can verify that the metadata describing the update was signed by the holder of your private key, and that a tampered download URL or a substituted version number is rejected before the user is offered anything.

The presence of a separate DSA helper tool is the interesting part of the design. Teams that already have a DSA key pair and an established signing workflow do not have to replace it, and the DSA tool exists for that case. The README lists it as a tool package with its own release, so it is versioned and distributed alongside the rest rather than being a script in the repository.

One caveat is worth stating plainly, since it is easy to assume otherwise. The private key has to live somewhere the build can reach, and the App Cast Generator is a global dotnet tool, so it runs on developer machines and on CI. Whether the key is protected by a passphrase, by a hardware token or by whatever your build environment provides is a decision the framework leaves entirely to you.

Which installer formats each platform accepts

The supported download types are listed per operating system, and they are narrower than a generic HTTP download would suggest. On Windows the framework handles .exe, .msi and .msp. On macOS it handles .tar, .tar.gz, .zip, .pkg and .dmg. On Linux it handles .tar.gz, .deb and .rpm.

Those lists define what you can publish. A Windows application shipped as a self-extracting archive or a raw zip will not be recognised as an installer, and on Linux anything that is not a .tar.gz, .deb or .rpm is out of scope even though the download itself would succeed. Since the list is per platform and the framework is cross-platform, a product that ships on all three has to produce three kinds of artefact.

That is the shape of the work NetSparkle saves you. It is not a packager, and it does not turn your build output into an installer. It recognises installers you already have, and the docs point to UPGRADING.md for the notes on major version changes.

Where the update flow stops and what it leaves to you

NetSparkle's role is bounded, and knowing where the boundary falls saves an argument later. It checks the app cast, presents the release notes, and offers the download and install. It is built for applications where the user is present and can accept a restart, which is the norm for desktop tools.

The main thing it does not do is decide when to check. The flow is user initiated in the built-in UIs, so a product that wants an automatic check on launch has to wire that call into its own startup code rather than expecting a background service. Silent installation and staged rollouts are likewise not part of what the framework describes.

There is also a data contract to keep. The app cast has to match what the client expects, the version comparison has to agree with how you number releases, and the release notes you publish have to be in Markdown or HTML. When an update does not appear for a user, the usual suspects are a version comparison that treats the new build as older, an app cast that the client cannot reach at the configured location, and a signature that no longer matches the file.

A different approach: letting the platform deliver the update

The real alternative to NetSparkle is not another library but a different delivery model. If your application is distributed through a platform channel that owns installation and updating, the update path belongs to that channel, and the app cast, the installer formats and the signature tooling all become unnecessary. The trade is that you accept the channel's release rules, its review process and its revenue terms in exchange for not building any of it.

NetSparkle takes the opposite side of that bargain. You keep control of the artefact, the download location and the timing of a release, and the price is a hosting responsibility, a signature to manage and a set of installer formats to produce for each platform you support. For a line-of-business desktop tool that customers install directly from your download page, that trade is usually worth making. For a consumer app that would go into a store anyway, it is usually not.

Between those poles sit the platform-specific tools in the wider .NET ecosystem, which update a single package feed rather than an application you ship yourself. NetSparkle is aimed at the application case, which is why the app cast, the release notes and the signing tools are the parts that get the most attention.

MIT licence, recent 3.x releases and a develop branch default

The licence is MIT, so the code can be used inside commercial products and the source can be read and modified. The repository keeps its licence in LICENSE.md and ships an OLD_CHANGELOG.md next to the current change history.

The release picture is worth attention because the 3.x line is recent and not yet old enough to have settled. NetSparkleUpdater 3.1.0 was released on 2026-05-05, the App Cast Generator package reached 2.9.0 on the same day, and 3.0.4 came out on 2025-10-05. That the generator and the runtime have separate version lines matters for upgrades, since the app cast format and the client that reads it have to agree.

The default branch is develop, so the code you see at the top of the repository is ahead of the last tagged release, and the documentation site is at netsparkleupdater.github.io/NetSparkle/. The last push was on 2026-10-13, and the README points to a Gitter chat room for questions, which is the fastest route to an answer about signing or app cast format edge cases.

Editorial conclusion

Adopt NetSparkle if you distribute .NET desktop software as your own downloadable installers and want a user-facing update flow with release notes, signature verification and no platform store in the loop. Do not adopt it for mobile apps, for software delivered through a platform channel that already handles updates, or if you want silent background installation, since the framework's job ends at offering the download and install. Verify three things first: the installer formats you actually publish against the supported list for your platform; that your app cast and signature tooling are set up correctly, since a mismatched signature check breaks updates rather than the install; and the major version notes in UPGRADING.md, because the 3.x line moved recently and the repository is on the develop branch. The licence is MIT, the latest package release is 3.1.0 dated 2026-05-05, and the last push was on 2026-10-13.

Frequently asked questions

Official sources

1. License: MIT
2. NetSparkleUpdater/NetSparkle on GitHub
3. Project website
4. README
5. Releases