0
votes

I'm struggling to get a ClickOnce setup working successfully with a bootstrapper. I'm building a VSTO add-in, and all worked well with a self-signed cert for development, but now we're setting up a proper certificate and it's failing in interestingly challenging ways.

The deployment uses a separate bootstrapper .exe, which is set as a dependency, to prompt for a few settings. Again, all this worked with a self-signed cert.

So the add-in builds okay, with a few post-build steps on the main component, as per:

"mage.exe"  -update "$(TargetDir)$(TargetFileName).manifest" -CertFile "E:\COMODOCodeSign.pfx" -Password _pass_
"mage.exe"  -update "$(TargetDir)$(TargetName).vsto" -appmanifest "$(TargetDir)$(TargetFileName).manifest" -CertFile "E:\COMODOCodeSign.pfx" -Password _pass_

The build works, the publish works, all looks good.

However, running the setup starts with the bootstrapper's EULA, and after acceptance, then I get the message:

Setup has detected that the file somewheretemp\bootstrapper.exe has either changed since it was published or may be corrupt.

Now, I am not "publishing" the bootstrapper. In the directory where it's stored as a dependency, there's no manifests, and I'm not signing it at all. So I can't see how/where it has decided that's changed.

And although there are answers on the web, they all involve poking through manifests to find differences, and there aren't any manifests for the bootstrapper, and there are no traceable references to the bootstrapper in the signed VSTO manifest. At least, not that I can find with a grep on the published output.

So to the questions:

  1. Any ideas how to proceed?
  2. Should I sign the bootstrapper? (manifests and/or assemblies) -- I did attempt this but it didn't seem to make any difference.
1

1 Answers

0
votes

The issue appears to be in Publish > Prerequisites... in the project properties. I'd set it to have an installation folder URL, but I'd not (yet) copied the files there, this was me attempting to test the installer before I got to that point.

As soon as I removed a URL from this field, all worked okay, and the bootstrapper application started correctly. So there might still be a challenge getting web install directories right, but this particular issue is resolved.