21

This is a philosophical question.

Given a hypothetical desktop application, and a desire to provide automatic updates (rather than forcing people to go to a website, check for an update, download an update, install), which of the two is more of a "best practice" approach?

  1. Like iTunes, it checks to see if there is a new version and prompts the user to download the new version. If so, it downloads a full install executable (in this case, a Windows Installer file (.msi)) that installs the full version (not just an upgrade to the previous version - too much to manage if there are multiple versions out there). So, let's say, it's version 10.1.1 - whether you are installing fresh or upgrading, you use the same file. After it downloads, it instructs the user to close the application and run the install file themselves.

  2. Similar to the other one, it checks for a new version and prompts user to download it, but instead of just downloading an executable and prompting the user to run it, it actually runs it for them - shutting down the program they have open, acquiring the necessary security to install files.

Issues with #2: many issues around closing down program, since the program can open other programs (Outlook and Excel), or what if the user was in the middle of something. Also around security, you need local administrator access to install, what if you don't have it? In later versions of Windows, you cannot just override the person's security.

Issues with #1: some people believe this will be too hard, too much effort for the end-user.

I would strongly prefer to go with #1 because it will save 80-120 hours on my project, and is simpler to implement and maintain. However, we have people who feel strongly on all sides.

What is a best practice for this sort of thing?

Improve this question
5
  • I'm not so sure it's philosophical, sounds like she's looking for a solution to me.
    – John Batdorf
    Commented Apr 15, 2011 at 19:56
  • So it isn't OK to ask Design/Architectural questions here?
    – Shannon Davis
    Commented Apr 15, 2011 at 20:08
  • My question is, why does #2 require the program to shut down and restart? If it's a security update then that's understandable, but a normal user closes and re-opens a program at least once a day if not more, so why not install it in the background, let the user run the program using the older version in memory, and then when they restart it use the new version that was installed. No fuss, no hassle.
    – Mike S
    Commented Apr 16, 2011 at 16:35
  • @Mike S: that's not possible on Windows (cannot overwrite executable files that are running) and even on Linux it's not a particularly good idea (if you open another instance, you'll have one running the old code and one running the new code -- if there's any IPC happening, it's even worse)
    – Dean Harding
    Commented May 22, 2011 at 9:04
  • From experience: if you check for updates, don't have your program do so daily at midnight or 3PM. That seems reasonable, but you end DDOS'ing your own servers. Just add up to 3600 seconds of randomness; it's not that urgent.
    – MSalters
    Commented Aug 2, 2011 at 11:54

8 Answers 8

Reset to default
31

Personally, I rather like Google Chrome's approach. A base directory with a launcher, and subdirectories for each installed version of the software. The launcher just looks for the highest version number and uses that and deletes older versions as needed. An updater task runs every so often to download and create new directories. When new versions are installed, the running application requests a restart to use the new version.

Improve this answer
4
  • 5
    +1 for pointing out Googles good behavior. The contrast is Adobe Acrobat Reader who as every 2nd day some apparently urgent patches to install, and disturbs one continually in one's work.
    – Ingo
    Commented Apr 16, 2011 at 13:04
  • I like this approach too. The downside is that it works only for per-user installations which don't require elevation. Once you have an elevation prompt, it doesn't really matter if you need a couple more clicks to perform the update (it's not silent anymore).
    – user23272
    Commented Apr 18, 2011 at 10:11
  • @Cosmin if you don't wish to use %appdata% you could use %ProgramData% to store the downloaded files. A more philosophically correct way would be to store the archive there, then elevate to install the next time the program is run.
    – Bacon Bits
    Commented Apr 18, 2011 at 11:56
  • LOVE this answer and I am putting it in my back-pocket (for now, the "Itunes" style download has found broad appeal for cost-savings reasons.)
    – Shannon Davis
    Commented Apr 20, 2011 at 16:40
4

You shouldn't create unnecessary startup entries to check for updates like Adobe Flash Player (it's hard to track them all down, and I can't figure out a way to disable the checks...) or iTunes. It annoys the user (geeks, anyways). A better option would be to check for updates at application startup like Firefox does.

A simple unintrusive "Install updates?" window won't annoy users. Let it update in the background while the user does other stuff, and then automatically start your application.

Just be sure to include a option:

Check for updates at:

  • Log-on (if you want to annoy geeks)
  • Application Startup (on by default)
  • Every few weeks (off by default)

Or something similar.

If it's worth the effort, I'd say go for it. That's your decision.

Improve this answer
2

I think you want a "ClickOnce" setup.

http://msdn.microsoft.com/en-us/library/142dbbz4(v=vs.90).aspx

ClickOnce is a deployment technology that enables you to create self-updating Windows-based applications that can be installed and run with minimal user interaction. ClickOnce deployment overcomes three major issues in deployment:

Difficulties in updating applications. With Microsoft Windows Installer deployment, whenever an application is updated, the user must reinstall the whole application; with ClickOnce deployment, you can provide updates automatically. Only those parts of the application that have changed are downloaded, and then the full, updated application is reinstalled from a new side-by-side folder.

Impact to the user's computer. With Windows Installer deployment, applications often rely on shared components, with the potential for versioning conflicts; with ClickOnce deployment, each application is self-contained and cannot interfere with other applications.

Security permissions. Windows Installer deployment requires administrative permissions and allows only limited user installation; ClickOnce deployment enables non-administrative users to install and grants only those Code Access Security permissions necessary for the application.

Improve this answer
4
  • This wasn't a question of the pros and cons of click once and MSI ( to which many of your conclusions are incorrect and/or incomplete ) but rather a question of best practices for auto updating solutions.
    – Christopher Painter
    Commented Apr 15, 2011 at 20:01
  • I do appreciate this information anyway and I'll share it with the developer to see if he had considered it as an option - perhaps he thought he would have to develop the updating process himself.
    – Shannon Davis
    Commented Apr 15, 2011 at 20:10
  • Well Christopher, take it up with MS, that's direct from MSDN. That's really a helpful comment too.
    – John Batdorf
    Commented Apr 15, 2011 at 20:12
  • When it codes to deployment technologies, it never suprises me when someone posting on MSDN gets it wrong. There are very few of us experts who really understand this stuff.
    – Christopher Painter
    Commented Apr 16, 2011 at 2:46
2

I personally came to appreciate applications that do something similar to the Sparkle framework. I guess it is a Mac thing only, but it essentially does the following (off the top of my head - I assume the behavior can be adjusted).

  1. Check for update (usually at application startup)
  2. If there is one, a separate window is shown with a nicely formatted changelog
  3. The user can then skip that version, install it or choose to be reminded later
  4. If he decides to install the application, a progress bar is shown underneath the changelog
  5. After the download the user can decide to quit the application and install immediately or to install after he quits the application

Considering that you are talking about .msi, this particular framework is not really applicable, but in this case I would rather go with some existing solution than reinventing the wheel.

Improve this answer
1

I would say you really have to know your user. If they are savvy and or have an intense interest in staying up to date, #1 will work.

Never underestimate the laziness of a user because when their program doesnt work anymore because they are no longer supported, you will get flooded with help desk calls later.

The time will either come from development (#2) or support (#1).

Improve this answer
1

What about this?

  • At application startup, check for new version and (optionally after asking the user) download it.
  • When the download completes, provide a button for the user which allows to reinstall and restart the application (use no dialog unless the update is critical).
  • At application shutdown, (optionally after asking the user) start the installer. In case the user refuses to do the install at this point (maybe they're in hurry), do it next time before the application starts.

You don't need to bother the user, you don't need to close anything...

Improve this answer
1

Why not something in the middle?

Prompt to download (or make option "download automatically"), after finishing prompt to install the downloaded update (execute the .msi). This way you negate downside of #2 (closing in the middle of user's work) and yet keeping the comfort with the cost of 1 more click.

The "Close and install update?" dialog should be easily accessible (but not annoying) when user declines at first. With having "Launch < program name >?" checkbox at the end of .msi will be almost like #2 with not really any more work

@security
Programs in modern Windows can request permission to perform actions requiring admin rights (the user is displayed prompt where (s)he types admin's password and then selects "yes/no" whether to grant permission)

Improve this answer
1

I have 124 Pawnshops who use my Pawnshop Management desktop app. Whenever I have a new update, I broadcast an email to them letting them know about the update and the details of it. Then they have the option to FTP it by logging into my website. They also have the option to rollback the update. My website also keeps track of each pawnshops installed version.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.