The Problem Recently had an issue on a project that had been paused for a few months. When we restarted the project we found that the SonarCloud PR analysis, running via an Azure DevOps YAML pipeline, was failing with a 404 error. The strange thing was that the same pipeline running analysis of the main trunk or the branch the PR related to worked without error. The Solution The issue was fixed by regenerating the SonarCloud PAT that was registered in the Azure DevOps project’s Service Connection. ...

The Problem Recently an Azure DevOps Pipeline for a .NET 6 based Azure Functions started to fail on some of our self-hosted build agents with the error ##[error]C:\Users\Administrator\.nuget\packages\microsoft.azure.webjobs.script.extensionsmetadatagenerator\4.0.1\build\Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.targets(37,5): Error : Metadata generation failed. Exit code: '-2147450750' Error: 'Failed to load the dll from [C:\hostedtoolcache\windows\dotnet\shared\Microsoft.NETCore.App\3.1.32\hostpolicy.dll], HRESULT: 0x800700C1An error occurred while loading required library hostpolicy.dll from [C:\hostedtoolcache\windows\dotnet\shared\Microsoft.NETCore.App\3.1.32]' The pipeline it self was simple, just repeating the steps a developer would use locally - task: UseDotNet@2 displayName: "Use .NET 6" inputs: packageType: sdk version: 6.x performMultiLevelLookup: true - task: DotNetCoreCLI@2 displayName: "dotnet restore" inputs: command: restore projects: "$(Build.SourcesDirectory)/src/Api.sln" feedsToUse: "select" vstsFeed: "aaa33827-92e2-45a0-924a-925b0d6344677" # organisation-level feed - task: DotNetCoreCLI@2 displayName: ".NET Build" inputs: command: "build" arguments: > --configuration ${{ parameters.buildConfiguration }} --no-restore projects: "$(Build.SourcesDirectory)/src/Api.sln" The Cause The issue was that the dotnet build was picking up a .NET 3.1 version of the hostpolicy.dll from the cache. This was even though the pipeline was set to use .NET 6, and I could see both .NET 3.1 and .NET 6 SDKs in the cache folder. ...

Around a year ago I posted on ‘Social Media Posts after Migrating from WordPress to Hugo Static Pages’. Recently I have found that the Twitter functionality in my Logic App was failing. Turns out this was due to the changes in the Twitter Free API, with them moving from V1 to V2 which requires OAuth authentication as opposed to a Bearer token. In essence the core of the problem is that the built-in Logic Apps Twitter Connector only supports the V1 Twitter API. So the only option was to create my own custom solution. ...

Updated: 19 Jul 2023 - Revised the post to use Az CLI Task as opposed to a PowerShell Task Updated: 29 Aug 2024 - Revised the PowerShell as original version was not working. Also see follow up post on using Workload Identity federation Background Azure DevOps Pipelines have a built in mechanism to run maintenance jobs on a schedule. This is great for cleaning out old temporary data, but what if you want to run your own maintenance job? ...

In a modern hybrid cloud world we have to accept constant change as the norm. You can’t just build something and forget about it. You have to keep it up to date as newer tools/libraries appear. This is to at least address security issues, even if you don’t want to adopt the new features. So I am expecting a degree of maintenance work on my Azure DevOps pipelines. However, this is becoming more awkward as many of the tasks used by Azure Pipelines, even ones from Microsoft, are themselves not being maintained. ...

I posted a while ago about how I had automated the generation of social media posts for my static Hugo based website using Azure Logic Apps. The other place I auto-generate social media posts is from releases via my project’s Azure DevOps Pipeline builds. These use a YAML Pipeline Template that calls a Marketplace task to post to Twitter and a PowerShell task to Invoke-WebRequest to post to Mastodon. Recently the Twitter task started to fail, and given the recent changes to the Twitter API with the move to the V2 API, I decided a new solution was required. ...

Background When working with Azure DevOps, you may need to access the REST API if you wish to perform scripted tasks such as creating work items, or generating reports. Historically, you had to use a Personal Access Token (PAT) to do this. If you look in my repo of useful Azure DevOps PowerShell scripts you will find all the scripts make use of a function that creates an authenticated WebClient object using a passed in PAT token. ...

Background We use Lability to build Windows Server images for our test labs. Lability makes use of Desired State Configuration (DSC) to build the VM images. Part of this process is for Lability to download DSC modules, as ZIP files, from a NuGet feed such as PowerShell Gallery to inject into the created VM image. Historically, we have stored our own private DSC modules on an internally hosted NuGet server. However, we wanted to move these modules to a private Azure DevOps Artifacts feed. The problem was that Lability does not support downloading of DSC modules from Azure DevOps Artifact feeds, whether they are public or private, because of the way the package URLs are constructed. ...

I make every effort keep all my Azure DevOps Pipeline extensions reliable as I know they are used by many people, but mistakes happen. Yesterday I released an updated version of my ReleaseNotes task that introduced a bug if the pipeline produced no artifacts. I am pleased to say I have fixed the bug, and addressed this gap in my test coverage. However, this did mean for about 12 hours if you are using this task in a pipeline that did not produce artifacts, maybe one that just deployed consumed artifacts from other pipelines, you had a failing pipeline. ...

Background At Black Marble we have our own private build agents, but they are built using the same Packer process as the Microsoft hosted ones. I recently rebuilt our agents to match the latest version of the hosted agents, and I ran into an issue with some .NET 3.1 based x86 MSTests. The tests were failing with the following error: A total of 34 test files matched the specified pattern. ##[error]Testhost process exited with error: A fatal error occurred. The required library hostfxr.dll could not be found. ##[error]If this is a self-contained application, that library should exist in [E:\Agent\_work\1\s\src\Ux.Common.UnitTests\bin\x86\Release\netcoreapp3.1\]. ##[error]If this is a framework-dependent application, install the runtime in the global location [C:\Program Files (x86)\dotnet] or use the DOTNET_ROOT(x86) environment variable to specify the runtime location or register the runtime location in [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]. When I checked the folder C:\Program Files (x86)\dotnet it was not there, .NET 3.1 x86 was no longer present on the agent. ...