Hello,
I have an authenticode certificate (.pfx) which I use to sign executables.
How can I configure Team Build so that it signs every single executable (.exe, .dll, ...) automatically while building the project?
A:
Don't.
You do not want to automatically sign builds. Most builds don't need signing anyway, they're only used for automate tests. Some build may be handed to your in-house testers. But only builds that you actually release outside your organization need Authenticode signatures. In that case, you should have a manual verification step after signing anyway. So, signing manually doesn't insert an extra manual step in the release process, and automating it saves very little time. In exchange, there will be far less signed files floating around in your organization, and you can make much stronger guarantees about the files that are.
MSalters
2009-08-28 14:57:15
Sounds reasonable not to sign everything everytime. However, we need to establish an automated process to sign the release version of the software. Also for verification through a platform test for Microsoft, every .exe, .dll and .msi needs to be signed.We have an automated process that gets the current sources, auto-version them, builds them, creates licenses and a directory structure, packages everything in MSIs, puts docs into the folders and finally zips everything for distribution. We would simply add another build script (MS Build -> Team Build) for the signing part. But how?
Mephisztoe
2009-08-28 16:20:30
Oh, I'm agreeing that you should sign the release version. And I'd agree with a mostly-automated process. Just put a pause prompt in the release process, before packing the binaries into the MSI. At that point you can easily sign the binaries you want signed. They are all created at this point, so it's easy to refer to them using a FOR loop or possibly even just a wildcard.
MSalters
2009-08-31 07:18:36
I disagree about "not bothering" to sign. We ship over 100 signed assemblies in our product, and they are packaged into an installer that is also signed. Not automating this would be madness. It's much better to test your actual release product than something "similar" to it, and it's safer if all your installers are obfuscated and signed so that an unprotected copy can't leak into the wild. We also run an Agile shop, so any build (that is good) is potentially a release. (We don't sign our CI build though, but that doesn't produce an exe that is actually used for anything)
Jason Williams
2010-07-22 20:11:36
Obviously you would tool your release process such that signing all 100 assemblies is a single manual step. But that's part of the release process, not the build process.
MSalters
2010-07-26 08:20:15
+1
A:
I disagree. Since the code signing certificate must be installed on the build computer in order to perform signing, why not sign everything that is built on that computer every time it is built? The computer is "at risk" because it has the code signing certificate installed, so it will need to be protected in some fashion (physical security and system security). If it is protected, why not let it do the work it was intended to do, prepare the files for delivery, consistently, repeatably, every time?
Unfortunately, the answer "don't" also seems to be the standard Microsoft answer, since they seem to provide almost no support in MSBuild to loop over a list of file names, calling a program once for each file name in the list. I've found ways to pass a wildcard generated list of files to the Signtool.exe program, but it can only handle one file at a time.
I fear (for me) that it is back to writing a batch file which loops over its arguments and calls signtool for each argument. Writing batch files for the common task of signing a build output makes me think MSBuild really isn't as mature a build system as it should be. Either that, or signtool has the wrong interface. In either case, signing multiple files without enumerating the name of every file to sign appears to be a "no go" with MSBuild.
Mark Waite
2009-10-29 23:55:55
I found a way of letting signtool iterate over a list of files from within a team build. Since it has to be done at solution level, the only drawback is that you need to speficy a filter for including/excluding files (e.g. you won't want to sign 3rd party libraries and you will only want to include exe and dll files).I you're interested, I can post some hints on our development blog (which is german however...)
Mephisztoe
2009-11-04 13:31:49
I would be interested in your method of iterating signtool over a list of files, and am happy to read it in German.
Mark Waite
2009-11-16 09:10:49
We just use a batch file that we <Exec> from MSBuild. Two lines of code (a trivial 'for' statement) that recursively iterate over all exes and dlls in the target folder, running signtool on each.
Jason Williams
2010-07-22 20:13:51