Pros and Cons of ClickOnce vs. DDay.Update
While DDay.Update is an alternative to ClickOnce, and uses the same
manifest files as ClickOnce (and hence the same publishing mechanisms),
I think it useful to declare the purpose of using DDay.Update
in leiu of ClickOnce.
In short, ClickOnce is primarily meant to deploy applications from the Internet, with as little
user intervention as possible to achieve this goal. DDay.Update takes this one step further
to simplify the process and to make otherwise difficult customization not only possible, but simple.
DDay.Update is not meant for initial deployment of your application - you'll need to use another
something else for that (InnoSetup works well); however, once installed, DDay.Update will provide
automatic updates and help manage the overall lifespan of your application.
That said, here are some of the pros and cons of ClickOnce and DDay.Update, denoted by feature sets.
| X |
- |
Supported |
| * |
- |
Upcoming feature |
| ^ |
- |
Possible, but difficult |
| + |
- |
Intentionally left out |
| Feature |
ClickOnce |
DDay.Update |
| Install Files |
X |
+ |
| Create Shortcuts |
X |
+ |
| Associate File Extensions |
X |
+ |
| Automatic Updates |
X |
X |
| Required Updates |
X |
X |
| Partial Updates (only update necessary files) |
^ |
X |
| Non-Programmatic Updates |
X |
X |
| Asynchronous Updates |
X |
X |
| Customizable User Interface |
^ |
X |
| Security permissions |
Grants only permissions necessary for the application (safer, but restrictive) |
Does not interfere with application permissions |
| Security Sandboxing |
X |
+ |
| Rollback to Previous Version |
X |
* |
While both ClickOnce and DDay.Update have additional feature sets, these are the main items worth comparing.