Why use True Update?

[AppleBag]

Not to sound like a troll, but what is the reason to use it as opposed to just placing a text file with the latest version number, on my server, and fetching it using simple http download code within my app, and comparing the version numbers to decide if there is an update available?

I'm interested in giving the trial a download out of curiosity, but I just can't seem to see why it might be needed?

The only thing I can think of is if there is some sort of complex situation?

[tigran]

In order to substitute TrueUpdate, you will need to solve the following issues:

1. What tool is going to be connecting to your server, checking for new version, and downloading the updates? You definitely shouldn't hard code that into your applications because every time you need to make changes to the download process, you will need to change, retest and rebuild all of your apps. Since the tool should be standalone, will you be able to build it in C++ in order to avoid a dependency for the executable? If your updater itself requires the installation of some sort of dependency (e.g. .Net Framework), than it's pretty much useless.

2. How are you going to solve the problem of updating the updater? The updating tool will need to capability so automatically download the updates for itself (not for application patching), and restart itself in order to ensure smooth update of the updater. This is not a trivial matter and you might end up spending months tweaking and debugging your own updater before it's reliable enough.

Once you work out those 2 issues, you can do just fine without TrueUpdate.

[Lorne]

Given enough money and time, you can do anything yourself.

It depends what your needs are. Anything beyond a very simple update system can cost you more in development time than the cost of TrueUpdate. You have to decide whether the time and effort could be better spent on other things.

Even a "simple" update system can become an expensive project once it is deployed and you start running into unexpected issues with proxies and access rights. You also have to be careful what you send upstream, in order to protect the user's privacy at the client end.

TrueUpdate is definitely a high-end solution, though, and for very simple updates it might seem a bit overkill. If your needs are truly basic and you have the skills you could certainly get by with rolling your own.

Some advantages of TrueUpdate vs. rolling your own solution:

• TrueUpdate is very robust; it has been tested extensively in the field and already handles many tricky little "gotchas" that make developing this kind of client-server system difficult
• it handles the very tricky problem of the client updating itself, or dealing with inadequate access rights to do so
• it allows you to change update behaviour at remote clients without requiring any changes to your application
• since it is script driven, there is no need to recompile your application when you make changes to the client or add new server locations (in many cases this alone can save enough time to pay for TrueUpdate quite quickly)
• it handles redundancy with multiple server locations (mirroring) and multiple protocols
• it can automatically publish your update-related files to multiple servers, ensuring that none of your mirrors are out of sync
• it already handles proxies, redirects and other tricky issues that you will probably need to deal with eventually
• the client is completely self-contained and compatible with older operating systems (difficult) and Vista (also difficult)