Strategy for moving from ClickOnce to MSI deployment

Question

We have a consumer app in the market that uses ClickOnce deployment. We've had various issues over time with ClickOnce, most of which have been resolved, but kind of always regretted not going with a straightforward MSI installer. In particular we'd like to be able to offer proper offline installs (from a boxed copy), and better multi-lingual installation options. We have just updated our beta to an AnyCPU build after finally getting shot of some old 32 bit dll dependencies (before you ask - yes, our app can really benefit from the increase in memory address space, we crunch a lot of data). Now of course we realise that going from x86 to AnyCPU doesn't work with ClickOnce, so it seems like the ideal time to make the switch away to another install technology.

SO here's the issue: we want to upgrade automatically to the new installer, from existing ClickOnce installations. We would also very much like to keep the user settings (.config) file. Not a total deal breaker if we can't, but it will irritate a lot of users if we don't.

So the very rough gameplan is something like this:

Create a new version of the app and deploy via ClickOnce. This new version is basically a front-end for the MSI installer. It somehow grabs the existing user settings, sets off a download of the new installer and invokes it. Then it copies the existing settings to the new application directory. Then it uninstalls itself (itself being the previous, ClickOnce, installation of the app).

In principle I think that could work, but am unsure about how to go about it. Particularly the moving of the user settings to the new application, and self-uninstalling at the end.

If anyone has any tips, or has gone through a similar process, I'd be very keen to hear about it.

Application is c# targeting .NET 4.

thanks, Matt

Answer 1

Create an msi version with the following features:

• Grab application settings etc from the ClickOnce installation. If it is the first start of the msi version for the current user, check if there is a ClickOnce version and copy/migrate the settings from there. I would not try to do the opposite way and push the settings from ClickOnce to msi because (1) there may be several ClickOnce installations with different settings and you may want to copy all of them and (2) You would have to put migration logic into the old version (which may be required to change for compatibility with future msi installed versions). The ideal approach, however, would be to just keep using the application settings as they were. If they are somewhere in the user profile (outside the ClickOnce installation), it should not matter how the application has been installed.
• Detect the ClickOnce version, offer the user to uninstall it. The ClickOnce version is installed once per user while the msi version can be installed for all users. If you started the uninstallation from within the ClickOnce version, you would only ever uninstall one of potentially several ClickOnce installations. If you do it as described here, every user will be reminded to uninstall his ClickOnce version once he starts the application (in ClickOnce or msi version).

Create a new ClickOnce version which detects the msi installed version.

• If no msi version is installed, tell the user about the new installer and offer him to download and run the new installer or do it later. I would not remove all other functionality. That could be a very evil surprise for a user. You should give the user the possibility to postpone the upgrade and use the existing version for some time. Remember that the user most likely did not need admin rights to update the ClickOnce-installed version but will need admin rights to install the msi.
• If it has been installed already, start the msi installed version and shutdown the ClickOnce version immediately. The less rigorous version would be to only inform the user. However, I would prefer to force the user to use the newer version once it is installed. Otherwise you may have compatibility issues in your working directory/application settings (depending on the exact structure of your application, of course).