Crimthann Crimthann - 1 month ago 21x
C# Question

Updating a ClickOnce application without bumping the version number

I have a ClickOnce application being distributed in various states of Australia and, depending on local machines, there are errors that arise. I need to find some way of updating a user without remoting into their computer and manually swapping out the dlls. Ideas that were had include tricking ClickOnce into thinking the current version is an older version, to force an update for the one computer.

The reasoning for this is to not bother the rest of the users with updates that do not effect them, as coordinating the locations is a large task.

--Progress Update--

Trying to trick ClickOnce, I have found 4 files that contain the product's version number, 3 cdf-ms files and 1 manifest. Two of the cdf-ms files (both in the manifests directory for the application) can break the application if the version number is altered, which seems promising to me.

They both have the string "%publicKeyToken%" a string of characters and then the version number. The string starts the same in both, one is finished with "typewin32%%%" while the other has "version%". I think I am traveling down a dead end, but it is something.

Altering version number after "version" gives the following error:

Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: RecordConnect.exe
Problem Signature 02:
Problem Signature 03: 56caca4f
Problem Signature 04: mscorlib
Problem Signature 05: 4.0.30319.34209
Problem Signature 06: 534894cc
Problem Signature 07: 7e6
Problem Signature 08: 0
Problem Signature 09: System.ArgumentException
OS Version: 6.1.7601.
Locale ID: 3081
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Altering version number after "typewin32" gives the following error:

Following errors were detected during this operation.
* [30/08/2016 12:20:29 PM] System.Runtime.InteropServices.COMException
- The referenced assembly is not installed on your system. (Exception from HRESULT: 0x800736B3)
- Source: mscorlib
- Stack trace:
at System.Deployment.Internal.Isolation.IsolationInterop.CreateActContext(CreateActContextParameters& Params)
at System.Deployment.Internal.Isolation.IsolationInterop.CreateActContext(IDefinitionAppId AppId)
at System.ActivationContext.CreateFromName(ApplicationIdentity applicationIdentity)
at System.ActivationContext.CreatePartialActivationContext(ApplicationIdentity identity)
at System.Deployment.Application.ApplicationActivator.Activate(DefinitionAppId appId, AssemblyManifest appManifest, String activationParameter, Boolean useActivationParameter)
at System.Deployment.Application.ApplicationActivator.ProcessOrFollowShortcut(String shortcutFile, String& errorPageUrl, TempFile& deployFile)
at System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri activationUri, Boolean isShortcut, String textualSubId, String deploymentProviderUrlFromExtension, BrowserSettings browserSettings, String& errorPageUrl)
at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object state)

--Progress Update--

Found the registry.


Inside is a whole host of places where the version number can be held. Looks like there are about 20 registry entries containing the version number. Most changes are harmless, one breaks the system and one actually triggers an update prompt. Unfortunately the update prompt has yet to actually update.

--Progress Update--

Messing around in the registry some more, saved a .reg file to make life easier. The .reg updated the ComponentStore_RandomString value and that triggered a reinstall. Not exactly what is desired but it is something.


The initial plan of altering a value to trick ClickOnce into thinking the program was of an earlier version is folly and I recommend none try to do that. ClickOnce is a very confusing system. However, I have discovered a way to trigger an update of the same version of the software.

In the registry, if you follow the following path


I have found two keys with long names that look like hex values to me. In these keys, there are 3 more keys that have a name that corresponds to my application, reco..tion. Two contain a similar extension, containing "0002.0001", but the last one just contains a long string (The public key token) followed by another, which does not change when reinstalled or when a completely different version of the software is installed. This is the folder mentioned in the initial post as the one that broke the application if it was changed. Once that is deleted, my software considers it a version change (because metadata containing that information is deleted) and reinstalls over the top of everything with the most current version.

I truly hope this helps others in my position, but given the amount of information I found out about it around the internet, I doubt many people are trying to do this silly task.