+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 even users with only standard privileges will still be able to update your app automatically... even transparently. Otherwise, you need extra IT staff involved with every deployment. This is a good idea even if your program is for the public at large; it will help you avoid a certain class of support issue. 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.

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

Take a look at the Microsoft Updater Application Block.

AppLife Update is worth every cent it costs.

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.