1

Similar posts that I've already seen but don't really address my issue:

I tried to ask this on Microsoft, but only got what seemed to be automated responses, so I'll try my luck here.

I purchased a certificate almost a year ago that I've been using to sign my ClickOnce deployed WinForms application. Since it's about to expire, I purchased a new one using the same data as before (although I accidentally used a different postal code; I'll mention this again below). I'm using a test web location to test publishing with the old certificate, and then publishing an update using the new certificate to see what the user experience would be. According to this article, if I'm using VS 2010 and .NET 4.0, users should get the update normally. I use VS 2017 and .NET 4.6.2, so I guess this should also apply to my case.

Except that when I publish the update, I get this warning:

The application is signed with a different key than the existing application on the server. Do you want to overwrite it?

If I publish it anyway, I don't see any update prompt on the machine where the product is installed, and if I manually download and install the new version, it installs it side-by-side with the old one with a "- 1" appended to the product name. Which I think is what happens when you install two separate ClickOnce applications that have the same name. So Windows thinks this is a different application instead of an update to the existing one.

I opened up both the old and new generated manifest files (MyApplication.exe.manifest) and noted that the publicKeyToken differs in the assemblyIdentity element:

<asmv1:assemblyIdentity name="MyApplication.exe" version="1.2.3.4" publicKeyToken="44de2eab9d920cfd" language="neutral" processorArchitecture="amd64" type="win32" />

vs

<asmv1:assemblyIdentity name="MyApplication.exe" version="1.2.3.4" publicKeyToken="6fec920a5f1bbb2b" language="neutral" processorArchitecture="amd64" type="win32" />

Also, the publisherIdentity element contains different postal codes since I mistakingly used a different postal code on the old and new certificates (although I did ask support to use the same data everywhere regardless of what I typed, since I purchased both from the same vendor). These two differences don't exist when I compare two versions that use the same certificate.

So my question can be reduced to just two questions:

  1. Does the publicKeyToken determine the identity of the application, such that if they are different, then Windows will treat them as separate applications (which would explain what is happening here)?
  2. Is the PostalCode attribute of the publisherIdentity used to generate the publicKeyToken (which would explain why my publicKeyTokens are different)?

If both are yes then at least I'll know why exactly I'm having this problem and I guess there'd be hope that purchasing a new cert with the right postal code may solve it. But I don't want to purchase yet another cert just to see if that fixes it, so I wonder if anyone had some experience with this or some insight into how this aspect of ClickOnce works.

Juan
  • 15,274
  • 23
  • 105
  • 187
  • I haven't read all this, but the title seems promising: https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2010/ff369721(v=msdn.10)?redirectedfrom=MSDN – Flydog57 Nov 07 '19 at 21:32
  • @Flydog57 Yeah I saw that but it doesn't seem to work here. I also mentioned it on my post. – Juan Nov 07 '19 at 22:10
  • Oh, and public key tokens are simply shortened versions of the public key associated with the private key used to sign the assembly. Take a look at @ericlippert's answer to this question for more info: https://stackoverflow.com/questions/1321419/what-is-the-role-of-public-key-token. Your postal code doesn't get involved at all. – Flydog57 Nov 08 '19 at 23:24
  • And... Have you asked the CA you purchased the cert from if they can renew your initial cert (rather than getting a completely new one). A simple search turned up this: https://docs.digicert.com/manage-certificates/code-signing-certificate/renew-code-signing-certificate/, which, to me, looks like there is at least one CA that will issue you a new cert (with new dates) based on the same key-pair – Flydog57 Nov 08 '19 at 23:27

0 Answers0