Signing a ClickOnce manifest through TFS Build 2008?

Question

I have a problem with how to "Sign the ClickOnce manifest" of my application from TFS Build.

I installed my subscription page in VS 2010 by checking the "Sign ClickOnce checkbox" checkbox and selecting our key to sign the code from the file, as shown in the following screenshot:

Now when I publish the application from VS 2010, the manifest seems to be successfully signed:

However, when I try to create an application from TFS Build, it does not seem to be trying to sign the manifest. In fact, an error message does not even appear indicating that something failed.

I tried setting up the TFSBuild.proj file so that my build server knew about the certificate and that I wanted to sign my manifests, but I was not sure how to do it.

I tried the following:

<CustomPropertiesForBuild>SignManifests=true;ManifestCertificateThumbprint=<thumbprint goes here></CustomPropertiesForBuild> 

But that doesn't seem to make any difference. (Errors are also not generated).

Note: I am not interested in the strong names of my congregations; just signing my code .

Does anyone know how to do this? Has anyone successfully deployed ClickOnce applications from a TFS build?

Answer 1

So far, the only way I have been able to sign my code through TFSBuild is to run the command line code signing tool. This basically consists of three steps:

• Import the certificate to the build machine that is logged in as any TFSService account that you use to run TFSBuild. After you import the certificate, you will need to log into Cert Manager to get its fingerprint (I think it is called a hash in the certificate manager user interface).

• Add the object to your .csproj / .wixproj / .whateverproj, which finds the signtool.exe file and runs it:

   <Target Name="SignOutput"> <PropertyGroup> <WindowsSdkDir>$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\@CurrentInstallFolder)</WindowsSdkDir> <WindowsSdkDir Condition="'$(WindowsSdkDir)' != '' and !HasTrailingSlash('$(WindowsSdkDir)')">$(WindowsSdkDir)\</WindowsSdkDir> <SignToolPath>$(WindowsSdkDir)bin\signtool.exe</SignToolPath> <Hash>...</Hash> <TsUrl>http://timestamp.verisign.com/scripts/timstamp.dll</TsUrl> </PropertyGroup> <ItemGroup> <SignableFiles Include="$(TargetDir)\Setup.msi" /> <SignableFiles Include="$(TargetDir)\Data.cab" /> </ItemGroup> <ResolveKeySource CertificateThumbprint="$(Hash)"> <Output TaskParameter="ResolvedThumbprint" PropertyName="LocatedThumbprint"/> </ResolveKeySource> <Exec Condition="'$(LocatedThumbprint)' != '' and Exists('$(SignToolPath)')" ContinueOnError="true" Command="'$(SignToolPath)' sign /q /sha1 $(LocatedThumbprint) /t $(TsUrl) '%(SignableFiles.Identity)'" /> </Target> 

• Call up a new target at the appropriate time; we only sign release builds, so we do the following:

   <Target Name="AfterBuild"> <CallTarget Targets="SignOutput" Condition="'$(ConfigurationName)' == 'Release'" /> </Target> 

This method also works on developer machines, assuming they have the proper SDK tools installed. If they do not, it will simply skip the signature step, which works great for us.

Answer 2

I did this for several clients, where I created the MSBuild general task, “Powershell Execution,” and then did the hard work for such things using Powershell scripts called TFS Build 2008.