Posts

I have been using the Microsoft Band (both version Band1 and Band2) since they came out, and been reasonably happy. However, a year or so on my issues with it have remained the same Poor battery life, I can live with charging it each day, but even with GPS Power-saver mode on I can’t go for any exercise over about 4 hours (bit of an issue for longer bike rides) It is not waterproof, so no swimming (and worried doing the washing up) Also there seem to be some build issues with the robustness of the Band2. I had to get mine replaced due to it not accepting recharging and the forums seems to report people suffering problems with the wrist strap splitting. That said, the warrantee service seems excellent, no complaints there, mine was swapped without any issue in a couple of days ...

The RadioTFS show that I was the guest on has just been published at http://radiotfs.com/Show/117. If you don’t listen to RadioTFS why not? It is a regular podcast (as you can see with over 100 episodes) on all things TFS and VSTS. A great way to keep up what is new in the technology space. Links to this and all my other recorded sessions can be found here

Just published a new VSTS extension with a couple of tasks in it. The aim to to help formalise the end of a release process. The tasks Allow you to set the retension ‘keep forever’ flag on a build (or all builds linked to a release) Update increment a build variable e.g. all or part of a version number, in a build (or all builds linked to a release) The first just replicates functionality I used to have in house for builds ...

I have been using Visual Studio Code for PowerShell development, but got a bit behind on reading release notes. Today I just realised I can make my Integrated Terminal a Code a PowerShell instance. In File > Preferences > user Settings (settings.json) enter the following // Place your settings in this file to overwrite the default settings { // The path of the shell that the terminal uses on Windows. "terminal.integrated.shell.windows": "C:\\windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe" } Now my terminal is a PowerShell instance, and you can see it has loaded by profile so POSH Git is work as well ...

I recently posted on my development process for VSTS Extensions, it has been specifically PowerShell based build ones I have been working on. During this development I have come across a few more gotcha’s that I think are worth mentioning 32/64 bit The VSTS build agent launches PowerShell 64bit (as does the PowerShell command line on dev PC), but VSCode launches it 32bit. Whilst working my StyleCop extension this caused me a problem as StyleCop it seems can only load dictionaries for spell checking based rules when in a 32bit shell. So my Pester tests for the extension worked in VSCode but failed at the command line and within a VSTS build ...

I wanted to add some level of static analysis to our Typescript projects, TSLint being the obvious choice. To make sure it got run as part of our build release process I wanted to wire it into our SonarQube system, this meant using the community TSLintPlugin, which is still pre-release (0.6 preview at the time of writing). I followed the installation process for plugin without any problems setting the TSLint path to match our build boxes ...

I thought I had a problem with our TFS Lab Manager setup, 80% of our environments had disappeared. I wondered if it was rights, was it just showing environments I owned? No it was not that. Turns our the issue was a UX/Scrollbar issue. I had MTM full screen in ‘Test Center’ mode, with a long list of test suites, so long a scroll bar was needed and I had scrolled to the bottom of the list ...

Background I am finding myself writing a lot of PowerShell at present, mostly for VSTS build extensions. Here I hit a problem (or is it an opportunity for choice?) as to what development environment to use? PowerShell ISE is the ‘best’ experience for debugging a script, but has no source control integration – and it is on all PCs Visual Studio Code has good Git support, but you need to jump through some hoops to get debugging working. Visual Studio PowerShell tools, are just too heavy weight, it is not even in the frame for me for this job. So I have found myself getting the basic scripts working in the PowerShell ISE then moving to VS Code to package up the task/extensions as this means writing .JSON too – so awkward ...

This is a copy of the guest post done on the Microsoft UK web site published on the 7th June 2016 This is a revised version of a post originally published in August 2014. In this revision I have updated version numbers and links for tools used and added a discussion of adapting the process to support VSTS. The code for this post can be found in my GitHub Repo In the past I’ve written on the theory behind migrating TFVC to Git with history. I’ve since used this process for real, as opposed to as a proof of concept, and this post documents my experiences. The requirement was to move an on-premises TFS 2013.2 Scrum Team Project using TFVC to another on premises TFS 2013.2 Scrum Team Project, but this time using Git. ...

Microsoft asked my to revise my August 2014 article on ‘Migrating a TFS TFVC team project to a Git team project’, this revised version is now live on their web site. The changes in the revision are updated links for tools, and information on how to use the technique with VSTS now some work item customisation is available.