+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:
- Administrator access at run time, even briefly
- 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.