Publish your VSTS extension using Team Build and Release Management


While I've released my VSTS Extension Tasks to GitHub and the Visual Studio Marketplace some time ago, I was reminded that I've never really blogged about it yet. You may wonder what it does.

The VSTS Extension Tasks are a set of tasks for Team Build and Release Management to package, publish, share and install extensions to your Visual Studio Team Services account or TFS 2015 update 2 server.

There are quite a few people using the extension to package and publish their Visual Studio Team Services and TFS extensions.

There's a few places with more information on how to use them:
I'm using these tasks to package and publish my other build tasks:
A few other MVPs/Rangers that are using these tasks include Richard Fennel, Rene van Osnabrugge, Peter Groenewegen and Utkarsh Shigihalli and others.

Publish your extension to a local TFS Update 2 server


With the availability of extensions for TFS I've been looking for an easy way to publish extensions and their updates to the local marketplace. While I'm sure that Microsoft will at some point integrate the two, for now you need to manually sync the extensions between the VSTS Marketplace and your local TFS Marketplace.

Turns out that the tools used to publish to the VSTS Marketplace work for the TFS one as well. to publish an extension you do need to pass in the service url manually and this took a little bit of fiddling to figure out what to put in there. Turns out that it takes the server root,

C:\t>tfx extension publish --root . --manifest-globs vss-extension.json 
    --service-url http://jessehouwing:8080/tfs --proxy http://localhost:8888
Checking if this extension is already published
It isn't, create a new extension.
Waiting for server to validate extension package...

=== Completed operation: publish extension ===
 - Packaging: C:\t\jessehouwing.jessehouwing-vsts-variable-tasks-0.0.0.vsix
 - Publishing: success
 - Sharing: not shared (use --share-with to share)

If your server isn't configured with Basic Authentication enabled, you can use the Fiddler hack to authenticate over NTLM. As you can see by the --proxy option int he command above, that's what I'm doing at the moment.

It should be relatively easy to build a PowerShell script that uses the --json option to list all extensions on the local TFS Marketplace and then check the online marketplace for a newer version to automatically sync extensions which have already been installed. Stick that in a Build Definition on a Schedule and your local marketplace will always be up to date with the latest versions. That's something for a future blogpost.

Automatically populate your Source branch when publishing to Sonar


When you enable your build definition to trigger on multiple branches, you may not want them all to publish into the same Sonar project. 

Sonar has the concept of Branches, they're simply appended to the Project Key with a `-`. This prevents an old Hotfix build from messing up the trend information of your current development. It also helps you configure different baselines for older versions (branches).

When building from the Visual Studio Team Services Build tasks you can configure the branch automatically by including the Build.SourceBranchName variable in your Project Key:

Some background on the values assigned to this variable can be found on the Visual Studio Team Build Variables documention:


The name of the branch the build was queued for.
  • For Git this is the last path segment in the ref. For example inrefs/heads/masterthe name ismaster.
  • For TFVC this will last path segment in the root server path for the workspace. For example in $/teamproject/branch the name is branch

Search This Blog


Most Reading