SimpleUpdater adds self updating to a .NET desktop app in one call
A simple automatic update library for .net. 一个炒鸡简单但是足够好用的自动更新库。
At a glance
- What is it?
- FSLib.App.SimpleUpdater is a Windows Forms oriented auto updater component for .NET that downloads a package over HTTP, applies it and offers a customisable interface with a rich set of events. It suits teams shipping a traditional desktop app that still need updates after installation.
- Who is it for?
- Adopt FSLib.App.SimpleUpdater if you ship a .NET Framework or .NET Windows Forms desktop application and want update checking and applying to take a single call rather than a bespoke downloader. Do not adopt it for a WPF application, since the documentation says WPF support is only on schedule, and do not expect it to work for a modern cross platform deployment, since the supported target frameworks run from .NET 2.0 to .NET 5.0.
- Can I use it commercially?
- Yes, with conditions. LGPL-3.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 45 days ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
One static call is the whole integration
FSLib.App.SimpleUpdater, also called SimpleUpdater.NET, is described as a rapid application automatic updater component designed for .NET and Windows Forms, which could be easily integrated into current applications, and it can also work for other applications via command line mode. The integration surface is a single static call in your Main function:
FSLib.App.SimpleUpdater.Updater.CheckUpdateSimple("http://localhost/update_c.xml");One line, with the URL of an update description, and the component takes over the rest. The audience is developers of traditional Windows desktop applications, the kind built on Windows Forms, who need the app to update itself after installation rather than asking the user to download and run a new installer. That is a real and common requirement, and the usual answer is to write a downloader, a version comparison, a file replacement routine and a restart, which is a surprising amount of code to write and a surprising amount of code to get wrong. The project also notes that WPF support is on schedule, which places it clearly in the Windows Forms lineage, and that the command line mode extends the reach to applications written in other languages, which is the part that makes it more than a WinForms convenience.
What the component actually does over HTTP
The feature list is short and each item corresponds to a piece of work you would otherwise own. All data is transferred over HTTP, which means the update server can be a plain static file host. The update is fully automatic, needing almost no extra code. There is a large set of events with a customisable user interface, so the update experience can match your application rather than looking like a bolted on dialog. A package builder is provided, and it supports building update packages from the command line, which matters because your build pipeline should produce the package rather than a developer clicking a tool. And delta upgrade is supported, which decreases bandwidth and time. That last one is the feature that decides the component for many desktop applications, because a full package for a large game or a suite of business software is a large download every time, and a delta against the currently installed version turns that into a small patch. The distinction from the alternative approaches is worth making explicit. The built in .NET facilities for deploying an application, ClickOnce for instance, and the Windows Store and MSIX packaging model, each bring their own installation model and constraints. This component works with what you already ship.
The four step integration, and what you host yourself
The documented integration steps are four, and the order matters. First, use the package builder to build update packages. Second, upload the packages you built to your server directory. Third, add the updater assembly SimpleUpdater.dll as a reference to your project, with the NuGet package recommended, where the package to search for is fishlee.net.simpleupdater. Fourth, add the update call to your Main function. The second step is the one that is easy to overlook. The component does not host anything for you. The URL you pass to CheckUpdateSimple points at an XML description of the available update, and the packages it references live on your server, which means you own the update manifest format, the hosting, the cache headers that control whether clients pick up a new version, and the rollback story when a new version turns out to be broken. The documentation does not describe the format of that XML, the update server headers, or the behaviour when the server is unreachable, and those are the details you will need to design around.
The framework range tells you what this is for
The supported platforms are listed as .NET 2.0, .NET 3.0 to 3.5, .NET 4.0 to 4.8 and .NET 5.0. That range is the clearest signal about the project, because it spans the entire history of the .NET Framework plus the first .NET Core based release. Such a range is not a list of platforms being marketed, it is a description of a component that has been kept compatible across a long period of Windows desktop development, and that is consistent with the release history. The versions are 4.2.3.1 from August 2015, 4.3.0.0 from March 2016 and 5.1.2.0 from August 2023. The last push to the repository was on 2026-09-08 and the repository is not archived, so there has been recent activity, but the newest published version is three years old. That combination is worth reading carefully. The code is being touched, yet the released artefact most teams would install is 5.1.2.0. If you pick this component, check what the recent commits changed before you plan around the 5.1.2.0 tag.
Where a desktop auto updater is the wrong answer
There are two clear boundaries. The first is platform and framework, and it is not a small one. The supported list ends at .NET 5.0, the design target is Windows Forms with WPF described as on schedule, and the command line mode is what extends it to other languages. A team shipping a modern .NET application on .NET 8 or later, or a cross platform application, or anything that installs through the Microsoft Store or as an MSIX package, is outside what this component was designed for. Store and MSIX distribution have their own update mechanism, and using both would be a mess. The second boundary is the security and operational model, and it is the one to think hardest about. An auto updater that downloads a package and applies it on the client is a remote code execution path by design, and the documentation here says only that the transfer is over HTTP. A deployment where update packages are fetched over plain HTTP without signature verification means anyone who can intercept or poison the response can run code as your user. If you adopt this, the question to settle is not whether the component can apply an update but how the package is authenticated. A signed manifest, or a package hash pinned in the XML description you host, is the minimum you would want, and the documentation does not tell you whether the component verifies one.
The licensing and the support channels
The project is licensed under LGPL-3.0, with the licence file at the root of the repository, and the code lives in a single SimpleUpdater/ directory alongside the documentation file, which is a very small surface to review. LGPL is a reasonable choice for a component you link into a proprietary desktop application, since it obliges you to publish modifications to the component itself rather than to the whole application, but read the terms for your own distribution model before shipping. The support arrangements are also unusual and worth knowing about before you depend on them. The official release and support page is hosted on the author's own site at fishlee.net, and questions or suggestions are directed to a knowledge community for the auto updater at ask.iccfish.com, described as recommended, with a general forum at forum.iccfish.com as the alternative. Both are the author's own venues rather than an issue tracker on the repository, and the repository itself carries only a .gitignore, the licence, the documentation file and the source directory, with no contributing guide or issue templates. For a library that is still in use in production applications, that is a factor to weigh.
Editorial conclusion
Adopt FSLib.App.SimpleUpdater if you ship a .NET Framework or .NET Windows Forms desktop application and want update checking and applying to take a single call rather than a bespoke downloader. Do not adopt it for a WPF application, since the documentation says WPF support is only on schedule, and do not expect it to work for a modern cross platform deployment, since the supported target frameworks run from .NET 2.0 to .NET 5.0. Before you start, confirm the NuGet package fishlee.net.simpleupdater still resolves for your target framework, and plan the update server side yourself, because the component reads an XML description you host.
Frequently asked questions
What is FSLib.App.SimpleUpdater?
It is a .NET component for adding automatic updating to an existing application, designed for .NET and Windows Forms and also usable from other languages through its command line mode. The project describes it as a rapid application automatic updater component that is easy to integrate into current applications.
How do I add SimpleUpdater to a .NET project?
You build an update package with the package builder, upload the packages to your server, add a reference to the updater assembly SimpleUpdater.dll, using the NuGet package fishlee.net.simpleupdater, and then add the update call to your Main function, for example `FSLib.App.SimpleUpdater.Updater.CheckUpdateSimple("http://localhost/update_c.xml")`.
Which .NET versions does FSLib.App.SimpleUpdater support?
The documented list is .NET 2.0, .NET 3.0 to 3.5, .NET 4.0 to 4.8 and .NET 5.0. The design target is .NET and Windows Forms, and the documentation says WPF support is on schedule.
Does FSLib.App.SimpleUpdater support delta updates?
Yes. Delta upgrade is listed as a feature, and the stated purpose is to decrease bandwidth and time by transferring only what changed. A package builder is also included, and it supports building update packages from the command line.
What licence is FSLib.App.SimpleUpdater released under?
It is released under the LGPL-3.0 licence, with the licence file at the root of the repository. Support questions are directed to the author's knowledge community at ask.iccfish.com or the general forum at forum.iccfish.com rather than to the repository itself.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/iccfish-fslib-app-simpleupdater)Was this useful?