continuous integration

Authenticode Signing Service and Client

September 12, 2016 Coding 2 comments , , , , ,

Authenticode Signing Service and Client


  1. One registration for the service itself



Supported File Types

  • .ps1 and .psm1 via Set-AuthenticodeSignature



Azure AD Configuration



In the appRoles element, add something like the following:

  "allowedMemberTypes": [
  "displayName": "Code Sign App",
  "id": "<insert guid here>",
  "isEnabled": true,
  "description": "Application that can sign code",
  "value": "application_access"






Server Configuration



Name Value Notes
CertificateInfo:Thumbprint thumbprint of your cert Thumbprint of the cert to sign with
CertificateInfo:TimeStampUrl url of timestamp server
Authentication:AzureAd:Audience App ID URI of your service from the application entry
Authentication:AzureAd:ClientId client id of your service app from the application entry
Authentication:AzureAd:TenantId Azure AD tenant ID either the guid or the name like


Client Configuration


You'll need to create an appsettings.json similar to the following:

  "SignClient": {
    "AzureAd": {
      "AADInstance": "",
      "TenantId": "<guid or domain name>"
    "Service": {



  - cmd: appveyor DownloadFile


  - ps: '.\SignClient\SignPackage.ps1'

SignPackage.ps1 looks like this:

$currentDirectory = split-path $MyInvocation.MyCommand.Definition

# See if we have the ClientSecret available

# Setup Variables we need to pass into the sign client tool

$appSettings = "$currentDirectory\appsettings.json"



foreach ($nupkg in $nupgks){
    Write-Host "Submitting $nupkg for signing"


    Write-Host "Finished signing $nupkg"

Write-Host "Sign-package complete"


usage: SignClient <command> [<args>]

    file    Single file
    zip     Zip-type file (NuGet, etc)

File mode:


                                  as input to overwrite. Defaults to
                                  input file if ommited
                                  Default is dual, to sign with both
                                  Sha-1 and Sha-256 for files that
                                  support it. For files that don't
                                  support dual, Sha-256 is used
    -s, --secret <arg>            Client Secret
    -d, --description <arg>       Description
    -u, --descriptionUrl <arg>    Description Url

Zip-type archive mode, including NuGet:


                                  as input to overwrite
                                  Default is dual, to sign with both
                                  Sha-1 and Sha-256 for files that
                                  support it. For files that don't
                                  support dual, Sha-256 is used
                                  files to sign within an archive
    -s, --secret <arg>            Client Secret
    -d, --description <arg>       Description
    -u, --descriptionUrl <arg>    Description Url



Enabling source code debugging for your NuGet packages with GitLink

September 23, 2015 Coding 3 comments , , , ,

Enabling source code debugging for your NuGet packages with GitLink

Recently on Twitter, someone was complaining that their CI builds were failing due to either being down or rejecting their packages. Fortunately, there's a better way than using SymbolSource if you're using a public Git repo (like GitHub) to host your project -- GitLink.

Symbols, SymbolSource and NuGet

Hopefully by now, most of you know that you need to create symbols (PDB's) for your release libraries in addition to your debug builds. Having symbols helps your users troubleshoot issues that may crop up when they're using your library. Without symbols, you need to rely on hacks, like using dotPeek as a Symbol Server. It's a hack because the generated source code usually doesn't match the original, and it certainly doesn't include any helpful comments (you do comment your code, right?)

So you've updated your project build properties to create symbols for release, now you need someplace to put them so your users can get them. Up until recently, the easiest way has been to publish them on SymbolSource. You'd include the pdb files in your NuGet NuSpec, and then run nuget pack MyLibrary.nuspec -symbols. NuGet then creates two packages, one with your library and one just with the symbols. If you then run nuget push MyLibrary.1.0.0.nupkg, if there's also a symbols package alongside, NuGet will push that to SymbolSource instead of If you're lucky, things will just work. However, sometimes SymbolSource doesn't like your PDB's and your push will fail.

The issues

While SymbolSource is a great tool, there are some shortcomings.
* It requires manual configuration by the library consumer
* It slows down your debugging experience. VS will by default check every configured Symbol Server for matching PDB's. That leads many people to either disable symbol loading entirely or selectively load symbols. Even if you selectively load symbols, the load is still slow as VS has know way to know which Symbol Server a PDB might be on and must check all of them.
* Doesn't enable Source Code debugging. PDB's can be indexed to map original source code file metadata into them (the file location, not contents). If you've source-indexed your PDB's and the user has source server support enabled, VS will automatically download the matching source code. This is great for OSS projects with their code on GitHub.

GitLink to the Rescue


After running GitLink, just include the PDB files in your nuspec/main nupkg alongside your dll files and you're done. Upload that whole package to NuGet (and don't use the -symbols parameter with nuget pack). This also means that users don't need to configure a symbol server as the source-indexed PDB's will be alongside the dll -- the location VS will auto-load them from.

An example

Over at xUnit and xUnit for Devices, we've implemented GitLink as part of our builds. xUnit builds are setup to run msbuild on an "outer" .msbuild project with high-level tasks; we have a GitLink task that runs after our main build task.

As we want the build to be fully automated and not rely on exe's external to the project, we "install" the GitLink NuGet package on build if necessary.





<Target Name='GitLink'>

<Target Name='Packages'>

There are a few things to note from the snippet:
* When installing GitLink, I use the -ExcludeVersion switch. This is so it's easier to call later in the script w/o remembering to update a target path each time.
* I'm currently using -pre as well. There's a number of bugs fixed since the last stable release.

The end result

