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:  1.0.0.0
 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.2.1.0.256.48
 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.

HKEY_CLASSES_ROOT\Software\Microsoft\CurrentVersion\Deployment\SideBySide\2.0

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.

I think the approach of trying to trick ClickOnce is going to be a painful and error-prone process. For most ClickOnce deployments I've seen, I'd lean towards the minimum required version setting here. You can use the minimum required version (in visual studio, go to project properties > publish tab > Updates... button) to allow users to continue running an older version of your application even though you've pushed out a newer version. It seems very ideal in your case to set the minimum required version to your current version that works for most people, and then push out the patch for everyone. Your customer with the problem can take the latest version to fix their issue, but no one else is forced to update because they're at the minimum required version. They can update whenever they want, knowing it won't really change anything for them.

Here's some documentation on using the minimum required version, so you can see if it fits for you, see the section on Making Updates Required specifically: https://msdn.microsoft.com/en-us/library/s22azw1e.aspx. Sorry if this answer isn't super specific, there's just so many settings that can impact this, like whether you're online-only, when the application checks for updates, etc.