As time passes I have found there is a need for more cross platform VSTS extensions as there is more uptake of VSTS beyond it’s historic Microsoft platform based roots. Historically most of my extensions have been Powershell based. Now this is not a fundamental problem for cross platform usage. this is due to the availability of Powershell Core. However, Typescript and Node.JS is a better fit I think in many cases. This has caused me to revise the way I structure my repo and build my VSTS extensions to provide a consistent understandable process. My old Gulp based process for Typescript was too complex and inconsistent between tasks, it even confused me! My process revisions have been documented in my vNextBuild Github’s WIKI, so I don’t propose too repeat the bulk of the content here. ...

BlogEngine.Net has served us well as a blogging platform for a good few years. However, it is no longer under active support, so it is time to move on, too much risk of future security issues to ignore the lack of support. After a bit of thought we decided on WordPress as a replacement. OK this has had its own history of problems, but it has an active community and is well supported and in the Azure Marketplace. ...

Whilst doing some NPM build work for VSTS Extensions I kept getting intermittent EPERM errors about renaming Windows files during NPM install (as discussed on GitHub)l. When you get this it completely blocks any development. As the Github issue discusses there are many possible reasons for this issue, and many proposed potential solutions. However the only one that worked for me was to restart VS Code; as this appeared to be locking the node_modules folder somehow. This was even though I could delete it via Windows Explorer without any problems. ...

I have working on getting a Windows 10 Universal application analysed with SonarQube 6.x as part of a VSTS build. The problem has been that when the VSTS task to complete the SonarQube analysis ran I kept getting an error in the form WARNING: Duplicate project GUID: "8ace107e-8e3c-4a1b-9920-e76eb1db5e53". Check that the project is only being built for a single platform/configuration and that that the project guid is unique. The project will not be analyzed by SonarQube. Project file: E:Build1\_work58sBlackMarble.Victory.Common.Module.csproj … plus loads more similar lines. The exclude flag has been set so the project will not be analyzed by SonarQube. Project file: E:Build1\_work58sBlackMarble.Victory.Ux.Common.csproj … plus loads more similar lines. WARNING: Duplicate project GUID: "1e7b2f4e-6de2-40ab-bff9-a0c63db47ca2". Check that the project is only being built for a single platform/configuration and that that the project guid is unique. The project will not be analyzed by SonarQube. 2017-06-09T15:50:41.9993583Z ##\[error\]No analysable projects were found but some duplicate project IDs were found. Possible cause: you are building multiple configurations (e.g. DEBUG|x86 and RELEASE|x64) at the same time, which is not supported by the SonarQube integration. Please build and analyse each configuration individually. Generation of the sonar-properties file failed. Unable to complete SonarQube analysis. Turns out the issue was that even though my CI build was only set to create an x86|Debug build the act of creating the .APPX package was causing both x64 and ARM builds to be build too, this was too much for SonarQube as it though I had a multiplatform build.. ...

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? 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 ...

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 ...

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… ...

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 ...

Background 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. ...

Rik Hepworth and myself have been doing our ‘Living the Dream – Real world DevOps with VSTS and ARM’ at a good few events over the past few months. We now, at last, have a recording of a version of it up on Black Marble YouTube Channel’s DevOps Playlist Enjoy….