17

I'm using Visual Studio 2008 SP1.

I have a Windows Forms application deployed internally using ClickOnce in a shared folder on the local network.

The test certificate pfx expires in 2035.

I have published the update to the internal shared folder several times.

Note that the project is only set to 'Sign the ClickOnce manifests' and does not sign the assembly.

Now, I again publish a new version of my application.

When users click on their icons to run the application we get this error (it had always updated prior to deploying with the test certificate).

Dirección URL de la implementación :
file:///C:/Documents%20and%20Settings/Usuario.NOTARIAS3/Men%C3%BA%20Inicio/Programas/GrupoBackup/Expediente%20Electr%C3%B3nico.appref-ms%7C
Dirección URL del proveedor de la implementación :
file://192.168.13.111/compartida/AdministradorWin.application La
activación de C:\Documents and Settings\Useuario.NOTARIAS3\Menú
Inicio\Programas\GrupoBackup\Expediente Electrónico.appref-ms| dio
como resultado una excepción. Se detectaron los siguientes mensajes de
error:
+ The deployment identity does not match the subscription


OPERATION PROGRESS STATUS * [2/20/2008 11:23:21 AM] : Activation of
C:\Documents and Settings\Usuario.NOTARIAS3\Menú
Inicio\Programas\GrupoBackup\Expediente Electrónico.appref-ms| has
started. * [2/20/2008 11:23:21 AM] : Performing necessary update
check as specified by the deployment.

ERROR DETAILS

  • [21/06/2010 20:33:10] System.Deployment.Application.DeploymentException (SubscriptionState)
  • La identidad de la implementación no coincide con la suscripción.
  • Origen: System.Deployment
  • Seguimiento de la pila: en System.Deployment.Application.SubscriptionStore.CheckUpdateInManifest(SubscriptionState
    subState, Uri updateCodebaseUri, AssemblyManifest deployment, Version
    currentVersion) en
    System.Deployment.Application.ApplicationActivator.PerformDeploymentUpdate(SubscriptionState&
    subState, String& errorPageUrl) en
    System.Deployment.Application.ApplicationActivator.ProcessOrFollowShortcut(String
    shortcutFile, String& errorPageUrl, TempFile& deployFile) en
    System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri
    activationUri, Boolean isShortcut, String textualSubId, String
    deploymentProviderUrlFromExtension, BrowserSettings browserSettings,
    String& errorPageUrl) en
    System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object
    state)

I use regedit to search for this key:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\7e3a7433abfe6213

PC non updated

AppId file://192.168.13.111/COMPARTIDA/AdministradorWin.application#AdministradorWin.app, Culture=neutral, PublicKeyToken=4b005ceeffd565b0, processorArchitecture=msil

Version = 1.0.0.14

FileName = Expediente Electrónico

Publisher = GrupoBackup

Folder Name = GrupoBackup

PC UPDATED (uninstall-reinstall, but I want to AVOID it)

AppId file://192.168.13.111/compartida/AdministradorWin.application#AdministradorWin.application, Culture=neutral, PublicKeyToken=4b005ceeffd565b0, processorArchitecture=msil

Version = 1.0.0.30

FileName = Expediente Electrónico

Publisher = GrupoBackup

Folder Name = GrupoBackup

SuiteName= OGF Suite

Changes PC Non updated - Pc updated are:

1.) Suite Name is new value (I set it in properties Publish tab in Visual Studio)

2.) Version

and 3.)

AdministradorWin.app

from file://192.168.13.111/COMPARTIDA/AdministradorWin.application#AdministradorWin.app,

vs

AdministradorWin.application,

from file://192.168.13.111/compartida/AdministradorWin.application#AdministradorWin.application,

If I uninstall and then reinstall the app from scratch it all works. However, I was trying to avoid having to do this.

I get this error when I try to deploy a project that was previously successful.

I re-tried, after deleting all the manifests, but still no joy.

Is there a way to fix this?

In Publish Options -> Manifests

Use application manifest for trust information is UN CHECKED.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Kiquenet
  • 14,494
  • 35
  • 148
  • 243

7 Answers7

37

Did you change your target CPU from Any CPU to x86?

If you changed this, you will have to reinstall the application.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
zezespecial
  • 475
  • 5
  • 10
  • This happened to me. I changed it back to CPUAny and then it worked again. Later I will change it back and have the users reinstall. – AtliB Oct 17 '11 at 11:09
  • 1
    I did exactly this today. changed it to AnyCPU - now the clients are saying, even after an uninstall, the problem persists. #stumped – Trevor Daniel Jun 20 '14 at 19:17
  • You can automate the reinstall if you need to https://stackoverflow.com/a/73017220/618660 – statler Jul 18 '22 at 06:49
4

'Check Publish -> Installation Folder URL' and make sure it is not set incorrectly (sometimes it only shows up during publishing process)

'Check Publish -> Updates...' and make sure the Update Location is not set incorrectly.

To be absolutely sure set both these to be the same as the Publishing Folder Location. You'll need to tick 'The Application should check for update - Before the application starts'.

I had to do this to fix issue in my case.

RagtimeWilly
  • 5,265
  • 3
  • 25
  • 41
  • 1
    I had changed update location from IP address (what was initially) to DNS name, when I changed it back, this issue was solved... – Prokurors Jun 27 '17 at 18:56
4

What do you mean when you say the following? "Changes: I set Suite Name value; Version and #AdministradorWin.app, vs #AdministradorWin.application".

It's the last bit I'm interested in. Did you change the assembly name?

There are a handful of settings that make up the identity of the deployment. Target CPU (as noted by zezespecial above), installation URL, and assembly name are three of them. Did you change any of these? What other changes did you make to the deployment?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
RobinDotNet
  • 11,723
  • 3
  • 30
  • 33
  • If you change it back, does it fix the problem? I can't imagine this actually causing a problem, but it's worth trying. – RobinDotNet Jan 21 '11 at 08:22
  • which settings make up the identity of the deployment? I have a similar problem – Martin Mar 22 '11 at 08:39
  • 3
    Deployment Provider URL (uses UpdateURL if filled in; if not, uses Installation URL if filled in; if not, uses Publishing File location). Target CPU. Name (which matches the assembly name). You can see them in the deployment manifest (.application). They don't use certificate any more (public key token), which is why you can change certificates w/o having to uninstall and reinstall. Post back exactly what the problem is? – RobinDotNet Apr 01 '11 at 08:23
  • 2
    Aha, thanks for the insight. In my case, the "InstallFrom" and "InstallURL" settings got modified accidentally. I changed it back (thank you SVN!) and it works now. – Mark Lakata Apr 20 '12 at 00:55
0

In my case, using Azure DevOps Pipelines, the project setting that generates the manifests got accidentally set to false somehow. I noticed it while comparing source control history versions of the project file. My fix was to manually (re)insert this property group into the csproj project file:

<PropertyGroup>
    <GenerateManifests>true</GenerateManifests>
</PropertyGroup>
Paul Schroeder
  • 1,460
  • 1
  • 14
  • 21
0

I had the "the deployment identity does not match the subscription" error after publishing a clickonce update.

I resolved this by:

  1. Delete the clickonce deployment folder contents (with "setup.exe").

  2. Delete the local (on the user PC) clickonce installation cache. Easiest is to delete all the contents of the folder: "C:\Users\[username]\AppData\Local\Apps\2.0" but this will delete all clickonce app installs.

  3. Recompile and republish the clickonce deployment.

  4. Reinstall the clickonce app on the client machine.

That resolved it for me.

Really cleaning out the client clickonce installation cache (#2 above) has resolved many different but similar issues for me a number of times.

Alex Martin
  • 156
  • 9
  • how-to clickonce installation cache using powershell or bat if you have any more 200 PCs client ? – Kiquenet Nov 15 '21 at 20:51
  • I am not too familiar with bulk / remote administration via powershell... But I think you could push a logon script out to your remote machines that goes and erases the contents of the cache folder (#2 above). I just tested this locally, and the installation and start menu icon will remain so as long as your clickonce app is configured to auto update the next time your users run the app it will reinstall itself. – Alex Martin Nov 17 '21 at 21:24
0

If you need to change the assembly target, installer location, cert etc, you can automate the uninstall/reinstall process. Refer my post at: https://stackoverflow.com/a/73017220/618660

statler
  • 1,322
  • 2
  • 15
  • 24
0

My problem was the Publication and Installation were different, but I did not indicate that was the case in the Publish section. Once I put C:\Temp for Publication and the URL where the application would run for Installation (http://....) the problem disappeared. Aloha

Tony
  • 1
  • 2