Our code-signing certificate expired recently, so I renewed it and just published our first version that uses the new certificate. Unfortunately, any customer who installs the upgrade loses the user-scoped application settings, and they get reset to the default values. I’m pretty sure that other upgrades always copied the user settings from the previous version, so I’d guess that there’s some problem related to the new certificate. We’re using a purchased certificate, not a test certificate. Our application is a WinForms application that targets .NET 3.5. The certificate authority seems to have changed hands in the three years since we bought the first certificate, so the issuer fields are different.
Is there any way to avoid losing the user settings when you renew a code-signing certificate?
Thanks to some hints from Jirka’s answer, it turned out to be a pretty easy fix. It looks like the user settings framework can see the previous version, but they just didn’t get upgraded for some reason. I used Mitch’s technique for upgrading user settings to manually call
Upgrade()the first time I run a new version. A useful trick for testing this upgrade process several times was Jason’s suggestion of copying old versions of the application manifest over the current version.It looks like I was fairly lucky. In some scenarios, customers have to completely uninstall and reinstall whenever you renew your certificate.
RobinDotNet wrote a comprehensive article on certificate expiration and ClickOnce. I found that there is a bug report, but it doesn’t sound very likely to get fixed. It sounds like targeting .NET 4.0 would make this problem go away, but the transition from 3.5 to 4.0 can be a bit tricky.
One thing that can make the expiry process a bit smoother is to timestamp the signing. That way, you don’t have to renew your certificate and publish a new version before the old certificate expires. The only timestamp server URL I’ve seen mentioned is this:
http://timestamp.verisign.com/scripts/timstamp.dll