Pages

Monday, March 6, 2017

TFS Continuous Integration - ClickOnce Apps

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.

https://social.msdn.microsoft.com/Forums/en-US/2d9414f5-1e78-4d33-b651-d09be74db80d/clickonce-publish-in-visual-studio-2015?forum=winformssetup

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!

2017-03-03_151212

2017-03-03_151303

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.

No comments:

Post a Comment