views:

382

answers:

6

If you have a Winforms app that is installed on a large number of machines, is there a standard way of implementing an automatic upgrade function?

e.g. Each time it is started, it checks a web site or web service and if there is a new version available, it downloads and installs it?

I could figure out how to roll my own version of this, but I'm wondering if there are any frameworks already in place to help with this.

+7  A: 

You may want to try out ClickOnce, I think it's possible with that.

eWolf
I think so too....
s_hewitt
Yes, you can do this with ClickOnce
hminaya
Definitely possible with ClickOnce - we haven't rolled it out on any large scale, but within a fairly limited scope it worked very well.
Murph
+1 ClickOnce works great for auto-updating. We have one app that is installed on over 100 PCs and we can upgrade it easily with ClickOnce. Although ClickOnce is great for upgrading, it does have other limitations (e.g. Non-customizable installer, doesn't install for all users, executable gets put deep in user's profile directory - not in Program Files, complicated certificate signing system that can break upgrades if not done correctly, etc). Make sure your application is a good fit for the ClickOnce model beforehand.
NYSystemsAnalyst
Thanks for the extra detail NYSystemsAnalyst. That could have been a separate answer...
codeulike
I had bad experience with ClickOnce, but we may have used it wrong.
Pierre-Alain Vigeant
+2  A: 

Take a look at the Microsoft Updater Application Block.

zac
Sounds interesting - was that replaced by ClickOnce or is it aiming for something different?
codeulike
I'm not 100%, but I think it's older. At least, it's listed as "retired" in the tree on the left, is targeted at .Net 1.1, and "helps you implement a pull model for automatically downloading updates" where I suspect you really need a "push" model.
Joel Coehoorn
+8  A: 

+1 on the ClickOnce answer, but I wanted to make a few comments on that as well:

Normally, when someone first starts out looking at ClickOnce they discover that it adds a number of new restrictions to things that their app is allowed to do. They nearly always violate at least one of these and come back declaring that ClickOnce doesn't work for them because x,y, and z won't work anymore.

Anticipating this will once again be the case, I want to take a moment to explain a rationale for these restrictions and why you might want to take a closer look at the way your app functions rather than write your own update system or go with an alternative.

The key thing here is to look at the primary use case for ClickOnce apps. That use case is mainly corporate workstations, where you want to deploy a real winforms line of business app that should always be up to date, but under no circumstances should users ever have administrator access to their own machine. Since you're talking about an "app that is installed on a large number of machines", I think it's likely you're in that category.

Looking at this use case, the last point especially is killer. In the end, most of the little restrictions on ClickOnce apps are things that would require one of the following:

  1. Administrator access at run time, even briefly
  2. Administrator access at update time

Sometimes it's not obvious that you need that access or why you need that access, but in the end that's usually what it comes down to. Want to register a dll with the system or update a file in the Program Files folder? That requires administrator access by default. Need to install or update a windows service? Administrator access. Want to run an msi installer for a third party component? You need Admin privileges to run msi's. Want to listen on a tcp port? You get the idea.

In the end, your goal is to make it so that a user with standard privileges will still be able to update your app automatically... even transparently. Otherwise, you need extra IT staff involved with every deployment. Going with an alternative deployment system won't change this. Those systems are just typically targeted at consumer machines where most users run as administrator anyway and so are less up front about the issues.

Joel Coehoorn
Hi Joel,Does ClickOnce be used to implement a push model for upgrades. I have used ClickOnce to deploy our app across the organization and clients had to run the application to start getting the updates. Is there any API available for sending updates from the server without client interaction (assuming all clients are connected to the network all the time)
theraneman
@Theraneman : ClickOnce can ensure an app is up to date every time it's run. What does it matter if the app is a few days out of date if the user hasn't run it?
Joel Coehoorn
+1  A: 

AppLife Update is worth every cent it costs.

erikkallen
+1  A: 

Let me start by saying we offer a complete updating solution which includes:

wyUpdate handles all of the Vista/Windows 7 UAC problems and all the file permission problems that inevitably pop up when you're trying to update complex software.

That being said, if you want to build your own updater here are some tips:

Building your own updater

A good place to start is the wyUpdate C# source code I mentioned above. You can cannibalize it and use it for your own purposes. Some of the algorithms it contains:

  • Full Windows Vista / Windows 7 UAC support
  • Ability for limited users to check and then update if they have credentials
  • Support for wonky corporate inernet. (If you've ever worked with a corporation this is a real problem).
  • Quick extracting, patching, and installing of files.
  • Registry support.
  • Roll back files & registry on error or cancellation by the user
  • Self-update

We have the file specifications here.

Automatic updating

Since being automatic is a requirement let me tell you how we do it with our AutomaticUpdater control.

We use named pipes to communicate between the standalone updater (wyUpdate) and the Automatic Updater control sitting on your program's form. wyUpdate reports progress to the Automatic Updater, and the Automatic Updater can tell wyUpdate to cancel progress, to start downloading, start extracting, etc.

This keeps the updater separate from your application.

In fact, the exact named pipes C# code we use is included in an article I wrote a little while back: Multi-process C# app like Google Chrome.

Wyatt O'Day
+1  A: 

I eventually used the Open Source 'Conversive Sharp AutoUpdater' at

http://csautoupdater.sourceforge.net/

Sharp AutoUpdater is a C# component that will automatically update your .NET application. Using XML configuration files, the AutoUpdater component detects if there is a new version of the software, downloads, unzips, and installs the new files.

Its fairly simpe - it downloads a zip and unzips it over the installed app - but it works well and was easier than writing my own. I don't think it handles things very well if users dont have admin access to their program files folder.

codeulike