How can I roll-back a ClickOnce application?

问题:

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.

回答1:

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

回答2:

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.

回答3:

You can go in Add/Remove application and select your application and choose to get the last installation instead.

回答4:

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

回答5:

If you look at your deployment location, you'll see every previous version, in a separate folder with the version number appended, as well as the deployment manifest, also with the version number appended.

You can rename any one of them to be the current deployment, and the next time you update that application, it'll pull in the version you rolled-back to.

回答6:

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

回答7:

This can be done via reflection if you know the publisher URI and the name, version language public key token and processor architecture of both the deployment and the application.

The below code will try to rollback the "coolapp.app" ClickOnce application. If it can't roll back, it will try to uninstall it.

using System;
using System.Deployment.Application;
using System.Reflection;

namespace ClickOnceAppRollback
{
    static class Program
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        static void Main()
        {
            string appId = string.Format("{0}#{1}, Version={2}, Culture={3}, PublicKeyToken={4}, processorArchitecture={5}/{6}, Version={7}, Culture={8}, PublicKeyToken={9}, processorArchitecture={10}, type={11}",
                /*The URI location of the app*/@"http://www.microsoft.com/coolapp.exe.application",
                /*The application's assemblyIdentity name*/"coolapp.app",
                /*The application's assemblyIdentity version*/"10.8.62.17109",
                /*The application's assemblyIdentity language*/"neutral",
                /*The application's assemblyIdentity public Key Token*/"0000000000000000",
                /*The application's assemblyIdentity processor architecture*/"msil",
                /*The deployment's dependentAssembly name*/"coolapp.exe",
                /*The deployment's dependentAssembly version*/"10.8.62.17109",
                /*The deployment's dependentAssembly language*/"neutral",
                /*The deployment's dependentAssembly public Key Token*/"0000000000000000",
                /*The deployment's dependentAssembly processor architecture*/"msil",
                /*The deployment's dependentAssembly type*/"win32");

            var ctor = typeof(ApplicationDeployment).GetConstructor(BindingFlags.Instance | BindingFlags.NonPublic, null, new Type[] { typeof(string) }, null);
            var appDeployment = ctor.Invoke(new object[] { appId });

            var subState = appDeployment.GetType().GetField("_subState", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(appDeployment);
            var subStore = appDeployment.GetType().GetField("_subStore", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(appDeployment);
            try
            {
                subStore.GetType().GetMethod("RollbackSubscription").Invoke(subStore, new object[] { subState });
            }
            catch
            {
                subStore.GetType().GetMethod("UninstallSubscription").Invoke(subStore, new object[] { subState });
            }
        }
    }
}

回答8:

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.

回答9:

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.