What alternatives are there to ClickOnce?

Question

I've used ClickOnce a lot over the years but have run up against a lot of it's limitations. What alternatives are there for web deployment?

So far the only one I've been able to turn up is ClickThrough, which is part of WiX now on the back burner. Are there any others out there that people have had success with?

Answer 1

What limitations are you having with ClickOnce?

When I don't use Click once I use NSIS (though you could use most other installer languages/systems) to make runnable, self installing application

i.e. When you run the download is run the application, there are no setup questions.

There is a menu option, or a frequent use detector that allows for permanent installation

The two hard issues are

1. Settings files
2. Local registry settings

For settings files I use remote web service to hold states etc

If you need local registry settings (file associations etc) then you need to do a proper install, but this can be done silently why the user is working with the application for the first time

Answer 2

After using WiX, NSIS and InstallAware, I have to humbly admit that they were all overkill for what I really need as a software developer. There are no projects that I've done so far which couldn't be deployed using the Visual Studio deployment project.

Is it limited? Yes.

It is also very simple to learn an use. Moreover, you actually can do really neat things like automatically create patches (.MSP files) by using techniques as described here

I fully understand that you can't do everything inside of a Visual Studio setup project, but it's rather surprising what you can accomplish. It's free, it's easy and, frankly, for general use is a better option than spending endless hours learning WiX's mind-boggling XML (impressive as it is), or InstallAware's verbose scripts...

With VS Setup, it's drag'n'drop & build'n'deploy. Every other solution I've tried had set backs... they can't automatically detect your project output... or need special filters so as not to include unwanted outputs from the build.

My suggestion is thus: If you simply wish to get your project deployed, then learn:

1. How to build a custom installer class, and
2. How to author your own pre-requisite packages

These are both reasonably easy skills to master, and satisfy the needs of most developers.

Answer 3

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.