TFS Continuous Integration - ClickOnce Apps
2017-03-06 15:45
The Summary
Oh, ClickOnce, you bane of development! You're always so attractive: easily created, self-updating installations. But, like a 21st century TV vampire, you end up sucking the life out of me when things get complicated.
In the case of continuous integration, we need to sign our application using a security certificate, to guarantee the publisher's identity. This makes sense, since the intent is that ClickOnce is installed and maintained from a web site.
http://stackoverflow.com/questions/8955332/what-is-signing-clickonce-manifests-for
So, there are two parts to manage in CI: the certificate and the signing.
There are several combinations for trying to build ClickOnce. Is your TFS on site, or are you using Visual Studio Online? Are you signing using a commercial, local-domain, or temporary certificate?
This document is for a specific circumstance:
- Local TFS 2015
- A temporary certificate
Note
This post will not deal with publishing a ClickOnce application via CI.
The Problems
So what happens when you try to build a ClickOnce app and on a separate CI server (without Visual Studio installed)?
It fails, that's what. At minimum, in the above scenario of using the default temporary certificate (which you shouldn't), it will fail because the signing utility, signtool.exe, isn't installed on the server.
How do you manage the signing process on a locally hosted machine?
Locally Installed TFS
Install SignTool.exe on the Server
When a developer creates a ClickOnce app, she must have the ClickOnce tools installed. In Visual Studio 2015, this is a feature checkbox during installation. If your forgot, you can open Programs and Features, right-click Visual Studio, and choose Change to rerun the installation.
But we're not going to install Visual Studio on the server.
Just the Files?
Can we create the appropriate folder path on the server and just copy the needed files, instead of installing 1GB of utilities? Maybe. It looks like the required files are:
signtool.exe
mssign32.dll
wintrust.dll
And the paths are:
C:\Program Files (x86)\Windows Kits\8.1\bin\x86
C:\Program Files (x86)\Windows Kits\10\bin\x86
I used the first path on Windows 10 and it worked fine. This is definitely worth testing before installing the SDK.
Via the Windows SDK
We need to install the super-bloated SDK. Which one?
If you're on Windows 8.1/10/2012/2012R2, install the Windows 10 SDK.
https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk
If you're on Windows 7/8/2008R2, install the Windows 8 SDK.
https://developer.microsoft.com/en-us/windows/downloads/windows-8-1-sdk
During installation, choose the Windows Software Development Kit. Funny, in Windows 10 they moved the SDK to the bottom!
Note
On my Windows 10 machine, running Visual Studio 2015, when I installed the ClickOnce tools, signtool.exe was installed to the Windows 8.1 SDK folder instead of Windows 10. It works...but go figure.
The Wrap Up
For my specific case, it was relatively easy to get signing to work during the build. If a non-temporary certificate had been involved, I could have installed that to the server.
This doesn't answer what to do if using Visual Studio Online or some other continuous integration server. That will be an adventure for another day.