0

My application is installed on ATM-like machines arouns the world. It is a WPF application which needs to be automatically updated behind the scenes and without user interaction at all.

Right now we're using Click-Once silent install API and it works perfectly. Our current functionality keeps checking constantly behind the scenes if there is a new version and if such exists, it updates the application, waits for the machine to be Idle (untouched by any users for 5 minutes) and only then it restarts the app. After the restart, a new version is loaded.

Is there a way i can achieve all this using MSI's ? Here's a summary of what i need:

  1. Remote and silent updates for all machines - i already know i can achieve this using LogMeIn and MSIEXEC (so no need to answer this bullet)

  2. Update the application while it is running, without restarting it.

  3. Restarting the application and running the new version only when the application is Idle for 5 minutes.

Any suggestions? If not MSI then any other installer perhaps? I Can't use clickonce because i want to set my application as the Shell (instead of cmd.exe) in Windows Embedded 8.

Uri Abramson
  • 6,005
  • 6
  • 40
  • 62

2 Answers2

0

It's an interesting high availability story and I can' think of a way to solve it and while MSI will work, it's not really an installer problem per say.

I'd create two installers: ContentManager and Application

The CM once finished should hardly ever change. It's job is to check for available updates and the idle status of the application. When an update is available and the application is idle it can perform a new silent side by side install of application in the background. Note I said install not upgrade. Now you have 2 versions of application installed. When the old application is still reporting idle it could be shutdown and the new version launched.

This would be highly available and MSI wouldn't need to know anything about the scenario. It's simply performing an install.

If you don't need it quite this highly available, then the other thing to consider is that Windows Installer supports "Restart Manager". Your WPF application can also. Your application could check for updates and start an upgrade. The restart manager interaction would then stop and restart your application during the upgrade.

The nice thing about the HA solution is your old version is still there. The content manager could back out the change simply by running the old version of the application.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
0

@Christopher Painter, Thanks for your response. A few thoughts:

The High-Availability solution is good at its base but it would require us to implement too much stuff on our own. A few things you haven't mentioned for such scenarios: 1. what happens if a download fails, what happens if the unzip fails, i would need to uninstall the previous version once install is complete, i would need to implement some security measures on my own (hashing for the 'version xml' or something like that...) how about shared resource locking? i would need to handle it on my own as well... Click once handles all this stuff nicely. Oh and one more thing i'd like to avoid is maintaining two applications instead of one as you suggested. I can't count on the 'Manager' so much that i wouldn't support updating it remotely. I can, however, use a 'push' methodology to activate the MSI using LogMeIn - It lets me upload and send a command to all machines (AMTs). The Restart Manager solution would work for me. Only thing i still haven't figured out is if i can make it hault until the application is Idle, and for how long (it must have some sort of a timeout). I've also researched MSI Custom Actions which can wait on a shared mutex ('idle'). What do you think?

Uri Abramson
  • 6,005
  • 6
  • 40
  • 62