ClickOnce de-signs our executable and says “Unknown Publisher”

Question

We are developing an application to be deployed via ClickOnce. We have a VeriSign code signing certificate that we are using to sign our application (via signtool.exe post-build) and our ClickOnce manifests. We are currently having two problems related to signing:

1. We are signing our .exe using our certificate. After building our application, we can see that it is signed (e.g., via "signtool verify /pa TheExecutable.exe"). But after installing the application via ClickOnce, the .exe is no longer signed.

2. We are signing our ClickOnce manifests using our certificate. But when we try to install the application via ClickOnce, the ClickOnce installer says "Unknown Publisher".

Issue #1 has always happened. Issue #2 has sometimes mysteriously disappeared, but it always comes back shortly thereafter, and we have been seeing it consistently for a few weeks now.

Any ideas?

Answer 1

Alright, solved the mystery for 1/2 of this question: ClickOnce takes the application manifest from bin, but takes the actual EXE from obj. In order to distribute your signed exe then, you must sign the file in the obj directory.

EDIT: Here's the other half. Installing .NET 4.5 Beta breaks ClickOnce signing / verification, even in VS2010.

Answer 2

Here is how I handle signing the manifest and signing the exe. I add this to the bottom of my .csproj file (edit it in a text editor).

  <Target Name="AfterBuild">
    <CallTarget Targets="SignOutput" />
    </Target>
    <Target Name="SignOutput">
    <PropertyGroup>
      <TsUrl>http://timestamp.comodoca.com/rfc3161</TsUrl>
    </PropertyGroup>
    <ItemGroup>
      <SignableFiles Include="$(ProjectDir)obj\$(ConfigurationName)\myappname.exe" />
    </ItemGroup>
    <Exec Command="signtool.exe sign /n &quot;My Company Name LLC&quot; /tr $(TsUrl) &quot;%(SignableFiles.Identity)&quot;" />
  </Target>

Answer 3

I'll be honest with you, Paul. I've never been really thrilled with ClickOnce. The toolset has never really seemed to mature except from the manual publishing/deploy side. Running the stuff through MSBuild has never been a good experience and Mage.exe always seems to have problems for me. Most of the time, my problems have revolved around the version number not being set correctly.

That said, I think our biggest troubles came from trying to manage things through the settings UI in Visual Studio. It has been helpful for me to try to rely a bit less on the MSBuild "magic" and pass the necessary parameters into MSBuild and take a little more control inside the csproj file.

I don't know what your build setup looks like, but, for us, we have Jenkins run a Rake file that invokes MSBuild on the solution. This allows us to send specific parameters into MSBuild from the Rake file.

Specifically, we push in values for ApplicationVersion, ApplicationRevision, MinimumRequiredVersion, and the OutDir. As far as things to watch out for in the csproj itself, you want to make sure that ManifestCertificateThumbprint, ManifestKeyFile, GenerateManifests and SignManifests are set. We also set the default build target to Publish, but I'm not sure that that's all that relevant.

I can't speak to why ClickOnce would be "de-signing" your executable aside from maybe the executable you're signing may not be the one you think is being packaged in the ClickOnce package. In other words, it may be building a new executable and throwing that in the package instead of the one you've already signed. I think I'd have to know a bit more about your setup in order to make that call for sure, though.

For what it's worth, if I could do it again, I wouldn't put my eggs in the ClickOnce basket. It's really only a great experience for those running Internet Explorer or if you've installed the plugin for Chrome. It's more work, but I'm currently working on a solution that mimics the Chrome update story. They have a ClickOnce package for Internet Explorer users, but it's really only used to download a Windows installer package that installs Chrome.exe and Update.exe. They go into plenty of details in the technical documentation for Omaha (otherwise known as Google Update).

Answer 4

There's a problem with signing the setup.exe yourself. I ran into this when writing ClickOnce articles for the P&P guys at MSFT. There is no workaround for it.

Is your certificate installed in the cert store for the user account you're using to generate the deployment? Is it specified as a file in the VS solution itself? If it's the default, and you generate the deployment using msbuild and mage, does it come out signed okay?