But it works on my PC!

The random thoughts of Richard Fennell on technology and software development

Restarting VS Code fixed NPM INSTALL intermittent EPERM issues

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.

A quick restart of VS Code and all was good again for a while, good enough to work with.

Duplicate project GUID blocking SonarQube analysis of Windows 10 Universal Projects

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\_work\58\s\BlackMarble.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\_work\58\s\BlackMarble.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..

The answer was to pass a parameter into the Visual Studio build task to disable the creation of the .APPX package.

The parameter override required is /p:AppxBundle=Never. This overrides the setting of Always that was set in the .CSProj file.

 

image

Once this change was done analysis completed as expected. Just need to fix all the issues it found now!

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

image

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": [

"node_modules"

]

}

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",

"configurations":

[

{

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

<PropertyGroup>

<TargetFramework>netcoreapp1.1</TargetFramework>

<Version>1.0.0.0</Version>

</PropertyGroup>

<ItemGroup>

<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" />

</ItemGroup>

</Project>

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. -->
<Include>
  <?define MajorVersion = "1" ?>
  <?define MinorVersion = "0" ?>
  <?define BuildNumber = "0" ?>
  <?define Revision = "0" ?>
  <?define FullVersion = "1.0.0.0" ?>
  <!--WiX Installer Versions are Major.Minor.Revision -->
</Include>

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="http://schemas.microsoft.com/wix/2006/wi">
  <Product Id="*" Name="WixProject" Language="1033" Version="$(var.FullVersion)"  Manufacturer="Test"
           UpgradeCode="510ca227-7d91-43f4-881c-13319a07b299">

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

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.

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

 

image

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!

Solution

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.

image

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

 

image