How can I roll-back a ClickOnce application?

Question

Is there a way (hacky will do) to allow a user to go back to a previous version of a ClickOnce network deployed application?

I've looked in the docs and API and there seems to be no way. You can selectively choose if you would like to update, but once updated there is, seemingly, no way back.

Answer 1

I understand ClickOnce version check algorythm as follows:

1. If version installed on client = version deployed to server - do nothing
2. If client version < server version - upgrade
3. If client version > server version:
   1. If minimumVersion specified on client >= server version - show error as we have
   2. If minimumVersion specified on client < server version - downgrade
   3. If minimumVersion is not specified on client - downgrade

Answer 2

Just used this to roll back a clickonce application developed in Visual Studio 2017. In my case, in the root folder, there were just two files; one called [applicationName].manifest, the other setup.exe.

The [applicationName].manifest contained a number references to the current version number but each were linked to a publicKeyToken value so I was reluctant to manually edit it.

So, in the Application Files folder, under to the sub folder containing the version I wanted to roll back to, I found another [applicationName].manifest, which I copied to the root folder (having backed up the original).

And that was it. It worked for me and was a really simple solution. However I'm not using a minimum required version so can't say whether that would affect it.

Answer 3

You can revert back to an older version on the server side by changing the server manifest file. When the client restarts the application, it will see that it has a different version than what the server says is the 'current' version, and it will download the new one. This server manifest file usually always points to the most recent version, but it doesn't have to.

Here's how to change it (I published using Visual Studio 2008. Other versions might have a different publish folder structure).

In the same folder as the publish.htm is an XML document called [appName].application. This is the server-side manifest file that the client uses to compare its current version against. Contained in this document includes the 'current' version that the client should be running as well as the location on the server that the deployment files can be found.

In the same location as the publish.htm is also a folder called 'Application Files'. This folder contains subfolders for each of the previous publishes. Within each of these sub-folders is another XML document with the same name I mentioned above called [appName].application. Copy this file (from whatever folder that contains the version you want to revert back to) and paste it into the same folder as publish.htm (a couple of levels up). When the client application restarts, it will appear just like a new version is available, download it, and run it. The client will now be running a previous version.

Answer 4

ClickOnce will use whatever version you send them. If you send them an old version, they will rollback to that old version.

Back in May my buddy David wrote an article on how to do this on a per-user basis. We can literally have every user on a different version. The application even tells the database which version the user wants, so they could in theory change their version and then simply restart the application.

Fine Grained Versioning with ClickOnce

Answer 5

You can use MAGEUI to rollback to a previous manifest version on the server. Check this out.

Answer 6

I just had to do one of these on my live production server, and it was nice to have all these notes. My solution was a bit different, and I wanted to add this as a fix as well. Before I do a production deployment I always backup the entire containing folder beforehand. I was able to copy my entire folder structure back into its original state and everything worked fine.

Notes of caution with this method:

• Your backup will be large if the application is quite big, or there are a lot of versions already published in the application files folder. Make sure you have enough room (for me storage is no object).
• Permissions have a nasty tendency of biting you this way. Ensure if your deployment location is hosted for external access that you verify all permissions before and after restoration.
• It was helpful for me to recycle my application pool in IIS.