Posts

The Problem Whilst doing a migration from an on-premised TFS to Azure DevOps Services for a client I had a strange issue with SQLPackage.exe. I had previously completed the dry run of the migration without any issues and started the live migration with a fully defined process and timings for a each stage. When I came to export the detached Team Project Collection DB I ran the same command as I had for the dry run ...

Updated 30/Sep/21 to reflect changes in the Aggregator CLI setup process Updated 27/Mar/22 to fix broken links Background Back in the day I wrote a tool, TFS Alerts DSL, to do Work Item roll-up for TFS. Overtime I updated this to support VSTS (as Azure DevOps was then called), it’s final version is still available in the Azure DevOps Marketplace as the Azure DevOps Service Hooks DSL. So when I recently had a need for Work Item roll-up I did consider using my own tool, just for a short while. However, I quickly realised a much better option was to use the Aggregator CLI. ...

The testing cycle for Release Notes Templates can be slow, requiring a build and release cycle. To try to speed this process for users I have created a local test harness that allows the same calls to be made from a development machine as would be made within a build or release. However, running this is not as simple was you might expect so please read the instruction before proceeding. Setup and Build Clone the repo contain the Azure DevOps Extension. ...

I have added another new feature to my Cross Platform release note generator. Now, when using Handlebars based templates you can optionally get the parent or child work items for any work item associated with build/release To enable the feature, as it is off by default, you need to set the getParentsAndChildren: true parameter for the task, either in YAML or in the handlebars section of the configuration. This will add an extra array that the template can access relatedWorkItems. This contains all the work items associated with the build/release plus their direct parents and children. This can then be accessed in the template ...

The addition of Handlebars based templating for my Cross Platform Release Notes Task has certainly made it much easier to release new features. The legacy templating model it seem is what had been holding development back. In the past month or so I have added support for generating release notes based on PRs and Tests. I am now happy to say I have just added support for the actual files associated with a commit or changeset. ...

Over the weekend I got another new feature for my Cross Platform Release Notes Azure DevOps Extension working. The test results associated with build artefacts or releases are now exposed to Handlebars based templates. The new objects you can access are: In builds tests – all the test run as part of current build In releases tests – all the test run as part of any current build artefacts or previous to the running of the release notes task within a release environment ...

We have been looking migrating some of our common .NET Core libraries into new NuGet packages and have taken the chance to change our build process to use Azure DevOps Multi-stage Pipelines. Whilst doing this I hit a problem getting SonarQube analysis working, the documentation I found was a little confusing. The Problem As part of the YAML pipeline re-design we were moving away from building Visual Studio SLN solution files, and swapping to .NET Core command line for the build and testing of .CSproj files. Historically we had used the SonarQube Build Tasks that can be found in the Azure DevOps Marketplace to control SonarQube Analysis. However, if we used these tasks in the new YAML pipeline we quickly found that the SonarQube analysis failed saying it could find no projects ##[error]No analysable projects were found. SonarQube analysis will not be performed. Check the build summary report for details. So I next swapped to using use the SonarScanner for .NET Core, assuming the issue was down to not using .NET Core commands. This gave YAML as follows,``` - task: DotNetCoreCLI@2 displayName: ‘Install Sonarscanner’ inputs: command: ‘custom’ custom: ’tool' arguments: ‘install –global dotnet-sonarscanner –version 4.9.0 ...

Back in early 2016 I wrote an Azure DevOps Extension to wrapper Pester, the Powershell unit testing tool. Over the years I updated it, and then passed the support of it over to someone who knows much more about Powershell and Pester than I Chris Gardner who continued to develop it. With the advent of cross-platform Powershell Core we realized that the current extension implementation had a fundamental limitation. Azure DevOps Tasks can only be executed by the agent using the Windows version of Powershell or Node. There is no option for execution by Powershell Core, and probably never will be. As Pester is now supported by Powershell Core this was a serious limitation. ...

This is one of those blog posts I write to remind my future self how I fixed a problem. The Problem I have a release that installs VSTest and runs some integration tests that target .NET 4.6 x64. All these tests worked fine in Visual Studio. However, I got the following errors for all tests when they were run in a release 2020-04-23T09:30:38.7544708Z vstest.console.exe "C:agent\_workr1aPaymentServicesdroptestartifactsPaymentService.IntegrationTests.dll" 2020-04-23T09:30:38.7545688Z /Settings:"C:agent\_work\_tempuxykzf03ik2.tmp.runsettings" 2020-04-23T09:30:38.7545808Z /Logger:"trx" 2020-04-23T09:30:38.7545937Z /TestAdapterPath:"C:agent\_workr1aPaymentServicesdroptestartifacts" 2020-04-23T09:30:39.2634578Z Starting test execution, please wait... 2020-04-23T09:30:39.4783658Z A total of 1 test files matched the specified pattern. 2020-04-23T09:30:40.8660112Z X Can\_Get\_MIDs \[521ms\] 2020-04-23T09:30:40.8684249Z Error Message: 2020-04-23T09:30:40.8684441Z Test method PaymentServices.IntegrationTests.ControllerMIDTests.Can\_Get\_MIDs threw exception: 2020-04-23T09:30:40.8684574Z System.BadImageFormatException: Could not load file or assembly 'PaymentServices, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format. 2020-04-23T09:30:40.8684766Z Stack Trace: 2020-04-23T09:30:40.8684881Z at PaymentServices.IntegrationTests.ControllerMIDTests.Can\_Get\_MIDs() … 2020-04-23T09:30:40.9038788Z Results File: C:agent\_work\_tempTestResultssvc-devops\_SVRHQAPP027\_2020-04-23\_10\_30\_40.trx 2020-04-23T09:30:40.9080344Z Total tests: 22 2020-04-23T09:30:40.9082348Z Failed: 22 2020-04-23T09:30:40.9134858Z ##\[error\]Test Run Failed. Solution I needed to tell vstest.console.exe to run x64 as opposed to it’s default of x32. This can be done with a command line override –platform:x64 ...

I decided to create a video of my blog post ‘Swapping my Azure DevOps Pipeline Extensions release process to use Multistage YAML pipelines’. [iframe width=“560” height=“315” src=“https://www.youtube.com/embed/WMQ0G9eXczE" frameborder=“0” allowfullscreen=”" allow=“accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture”] The video up on YouTube