The blogs of Black Marble staff

Book your free place at a Global DevOps Bootcamp venue for the 17th June 2017 event

Are you enthused by the all news at Build 2017?

Do you want to find out more about VSTS, DevOps and Continuous Delivery?


Well why not take the chance to join us on June 17th at Black Marble, or one of the over 25 other venues around the world for the first Global DevOps Bootcamp?

gdb-logo (002) (002)

The Global DevOps Bootcamp is a free one-day event hosted by local passionate DevOps communities around the globe. Find your local venue on the Global DevOps Bootcamp website or search for Global DevOps Bootcamp on EventBrite

Learn about the latest DevOps trends, ‘get your hands dirty during the Hackaton’, gain insights in new technologies and share experiences with other community members. All based around the concept of "From Server to Serverless in a DevOps world". The Global DevOps Bootcamp is all about DevOps on the Microsoft Stack


Remember, places are limited at all venues so make sure you get your name down soon to avoid disappointment

Options migrating TFS to VSTS

I did an event yesterday on using the TFS Database Import Service to do migrations from on premises TFS to VSTS.

During the presentation I discussed some of the other migration options available. Not everyone needs a high fidelity migration, bring everything over. Some teams may want to just bring over their current source or just a subset of their source. Maybe they are making a major change in work practices and want to start anew on VSTS.

To try to give an idea of the options I have produced this flow chart to help with the choices

Click for a PDF version


It mentions a few 3rd party tools in the flowchart, so here are some useful links

Also, if you find yourself in the orange box at the bottom and don’t want to use the TFS Database Import Service for some reason, have a look at this post I did on Microsoft’s UK Developers site. It might give you some ideas

Debugging Typescript in Visual Studio Code

This is one of those posts I do as a reminder to myself. I have struggled to get debugging working in VSCode for Typescript files. If I set breakpoints in the underlying generated JavaScript they worked, but did not work if they were set in the Typescript source file. There are loads of walkthroughs and answers on Stackoverflow, but all with that vital little bit (for me) missing. So this is what I needed to do for my usage scenario…

Whilst developing a Node based VSTS extension I have the following structure

Git repo root (folder)

--- .vscode (folder)

------ launch.json

--- mystuff.src   (the source .TS files)

------ script.ts

------ tsconfig.json

--- mystuff    (the target folder for the .JS files)

I develop my Typescript in the .src folder and use the TSC compiler to generate the .JS file into the target folder, running the ‘tsc –p .’ command whilst sitting in the .src folder.

Note: I actually run this Tsc command using Gulp, but this post does not need to go into detail of that.

The key thing is to make sure the two .json files have the correct options

The tsconfig.json is


"compilerOptions": {

"target": "ES6",

"module": "commonjs",

"watch": false,

"outDir": "../mystuff/",

"sourceMap": true


"exclude": [




The important lines are highlighted

  • The path to generate to .JS to – for me it was important to generate to a different folder as this made it easier to create the VSTS extension packages without shipping the .TS files by accident.This was part of my debugging problem as if the .ts and .js files are in the folder the should be no issues
  • Creating the source map which enables debugging, the .JS.MAP files

The launch.json is


"version": "0.2.0",




"type": "node",

"request": "launch",

"name": "Node – my stuff",

"program": "${workspaceRoot}/mystuff.src/script.ts",

"outFiles": ["${workspaceRoot}/mystuff/*.js"]




The critical lines, and the ones I messed up are

  • Program must point at the .TS file
  • Outfiles must point to the location of the .JS and .JS.Map files in the target folder and those square brackets [] are vital

Once I had all this in place I could set breakpoints the .TS file and they worked

Two new tasks in my Manifest Version VSTS Extension

I have just released a new version of my VSTS Manifest Version Extension (1.5.22). This adds two new tasks to the set of versioning tasks in the extension. The complete set now is


  • VersionAssemblies - sets the version in the assemblyinfo.cs or .vb (used pre build)
  • VersionDotNetCoreAssemblies - sets the version in the *.csproj (used pre build)  - cross platform
  • VersionAPPX - sets the version in the Package.appxmanifest (used pre build)
  • VersionVSIX - sets the version in the source.extension.vsixmanifest (used pre build)
  • VersionDacpac - sets the version in a SQL DACPAC (used post build)
  • VersionNuspec - sets the version in a Nuget Nuspec file (used pre packing)
  • VersionSharePoint - sets the version in a SharePoint 2013/2016/O365 Add-In
  • VersionWix - sets the version in a Wix Project


As with all the other tasks, these new tasks aim to find files recursively to update with a version number extracted from the build number

Version .NET Core CSPROJ file

This is a cross platform task, written in Node.JS. It updates a version number in a .NET Core .CSPROJ file. There is a parameter so it can look for different XML node names

<Project Sdk="Microsoft.NET.Sdk.Web">






<PackageReference Include="Microsoft.AspNetCore" Version="1.1.1" />

<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.2" />

<PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="1.1.1" />

<PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="1.1.1" />

<PackageReference Include="Microsoft.VisualStudio.Web.BrowserLink" Version="1.1.0" />



Version a Wix project

As Wix is a Windows technology, my new Wix task is only supported on Windows (PowerShell) build agents.

Due to the flexibility (complexity?) of Wix it does have to make some assumptions. I have documented them in the VSTS extension’s project wiki.

The summary is you need to put all the version number variable definitions in an installerversion.wxi file that is included into your Wix project. The task looks for and updates this file(s)

<?xml version="1.0" encoding="utf-8"?>
<!-- Note that this file will be overridden by the build server. -->
  <?define MajorVersion = "1" ?>
  <?define MinorVersion = "0" ?>
  <?define BuildNumber = "0" ?>
  <?define Revision = "0" ?>
  <?define FullVersion = "" ?>
  <!--WiX Installer Versions are Major.Minor.Revision -->

These variables can be used anywhere in the Wix project where needed e.g. to set the MSI version you could do the following

<?xml version="1.0" encoding="UTF-8"?>
<?include InstallerVersion.wxi ?>
<Wix xmlns="">
  <Product Id="*" Name="WixProject" Language="1033" Version="$(var.FullVersion)"  Manufacturer="Test"

If you want a different number format just build it from the individual parts.

Hope you find them useful, as usual asked question on VSTS Manifest Version Extension Q&A or raise issues on Github

401.1 Permission error with on-premises TFS when accessing the API with a PAT


If you are creating VSTS build extensions you will need to get the build or release’s PAT token if you wish to call the VSTS REST API.

This is done using a call like this (Node)


import tl = require('vsts-task-lib/task');

var auth = tl.getEndpointAuthorization('SYSTEMVSSCONNECTION', false);

if (auth.scheme === 'OAuth') {

var token = auth.parameters['AccessToken'];


or (PowerShell)


$vssEndPoint = Get-ServiceEndPoint -Name "SystemVssConnection" -Context $distributedTaskContext

$personalAccessToken = $vssEndpoint.Authorization.Parameters.AccessToken


You pop the resultant PAT into the headers of your REST web request and you are away and running.

The Problem

I hit a problem using this logic on VSTS Extension when they are run on TFS. On VSTS all was fine, but on TFS I got an unexpected 401.1 permission error on the first REST call i.e. I could not access the VSTS REST API

I tried setting fiddling with rights of my build user account, it was not that. Also I tried setting the ‘Allow scripts to access OAuth token’ property for the build/release agent



But this does not help either. This option just makes the PAT available as an environment variable, so you don’t need to use the code shown above.

And anyway – it was all worked on VSTS so it could not have been that!


The answer was I had basic authentication enabled on my Test TFS VM, as soon as this is disabled (the default) everything leapt into life.


Presenting at an event in Leeds - Making it easy to migrate your ALM process to the Cloud

Do you find your TFS server gets forgotten?

  • It is not owned by the IT department and the Development team don’t have the time to support it fully, it never gets patched or upgrades?
  • Or maybe you are adopting a cloud first strategy for all you systems?

Well maybe it is time to consider moving your on-premises TFS instance to VSTS?

On the 9th of May at the Crowne Plaza Hotel in Leeds I will be presenting at a Black Marble /Microsoft event where we will be looking at Microsoft’s new high fidelity VSTS database import tools that can be used to move a TFS instance to VSTS.

I will also be considering the pros and cons of the other migration options available to you. Hopefully making this a very useful session if you are considering a move to VSTS from TFS or any other source control ALM solution.

Hope to see you there, to register click here



New Cross Platform version of my Generate Release Notes VSTS Extension

My Generate Release Notes VSTS extension has been my most popular by a long way. I have enhanced it, with the help of others via pull requests, but there have been two repeating common questions that have not been resolved

  1. Is it cross platform?
  2. Why does it show different work items and commit associations to the VSTS Release Status UI?

Well the answer to the first is that the core of the logic for the extension came from a PowerShell script we used internally, so PowerShell was the obvious first platform, especially as though my PowerShell skills are not great, my Node was weaker!

The second issue is due to my original extension and VSTS’s UI doing very different things. My old extension was based around inspecting build results, so when working in a release it finds all the builds between the current release and last successful one and looks at the details of each build in turn, building a big list or changes. VSTS’s Release summary UI does not do this, it make a few current undocumented ‘compare this to that’ API calls to get the lists.

In an attempt to address both these questions I have over the past few weeks created a new Cross Platform Generate Release Notes Extension. Now don’t worry, the old one is still there and supported, they do different jobs. This new extension is cross platform and tries to use the same API calls the VSTS Release summary UI uses.

There are of course a few gotchas

  • I did have to adopt a work around for TFVC changeset history as Microsoft use an old internal API call, but that that was the only place I had to do this. So apologies if there are any differences in the changesets returned.
  • The template format is very similar to that used in my original Generate Release Notes VSTS extension, but due to the change from PowerShell to Node I had to move from $($widetail.fields.'System.Title') style to ${widetail.fields['System.Title']}

So I hope people find this new extension useful, I can now go off happily closing old Issues in GitHub