auto update for winforms application

Question

When creating an auto updating feature for a .net winforms application, how does it update the .dll's and not effect the currently running application? Since the application is running during the update process, won't their be a lock on the .dll's (because those .dll's will have to be overwritten during the update.

Answer 1

Usually you would download the new files into a separate area. Then shutdown and restart and at startup you look for and use the new files if found. Always keeping a last known working version on the side so that the user can revert to something that definitely works if the download causes problems.

ClickOnce is a good technology from Microsoft that does this for you and you can use it directly from Visual Studio 2008.

Answer 2

If you publish via ClickOnce, all of that tends to be handled for you. It has it's own pro's and con's but usually easier than trying to code it all yourself.

Both Wikipedia and 15seconds have decent info on using ClickOnce, how it works, etc.

As others have stated, ClickOnce isn't as flexible as rolling your own solution but it is a LOT less complicated. It has a small learning curve at first, but with pretty much everything bundled into Visual Studio and the use of Wizards, it usually doesn't take long to stumble onto a working solution.

As deployments get more complex (i.e. beyond than just having prerequisites or application code that needs updating) and you need to do a lot of post-install or pre-install tasks, there are things like WiX which give you somewhat of a hybrid solution between Windows Installer and ClickOnce, with the cost of flexibility being a much steeper learning curve.

The only reason I try to avoid custom installers is that you end up spending way too much time trying to get it just right to handle a bunch of different "What If" scenarios...

Answer 3

I have a seperate 'launcher' application that checks for updates via a web service. If there are updates, it downloads them and then executes my application, which is in a seperate assembly.

The other alternatives are using things like ClickOnce, or downloading the files to a seperate area and restarting the app, as someone else mentioned.

Be warned about ClickOnce, though - it's not as flexible as it sounds. And if you deploy to a system that requires elevating your program to a higer security level to run, you might run into problems if you don't have a certificate for your app installed. I found it very difficult to get straight answers on the Internet to things like certificate management when it comes to ClickOnce. If you have a complex app, you may want to just roll your own updater, which is what I ended up having to do.

Answer 4

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

• An open source updater, wyUpdate, written in C#
• The free AutomaticUpdater control that you can just add to your .NET app's form
• wyBuild is used to build patches and manage your versions

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 (no files left behind)

We also 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.

Answer 5

You'll have to shutdown your application and restart it, as other people have already commented.

I wrote an open-source code to do just that in a transparent mode - including an external update application to do the actual cold update. See http://www.code972.com/blog/2010/08/nappupdate-application-auto-update-framework-for-dotnet/

The code is at http://github.com/synhershko/NAppUpdate (Licensed under the Apache 2.0 license)