Tech Tips

Background It is becoming increasingly important to sign files digitally to ensure that they have not been tampered with, to secure the software supply chain. This is something we have done for a good while as a step in our Azure DevOps pipelines. However, recent(ish) changes in the way certificates are issued has meant we have had to revise our approach. The Problem We used to use a .PFX file, stored as an Azure DevOps secure file, that contained the public and private keys and was accessed using a password, to sign our files. ...

I really like Web Deploy, it is a powerful tool for injecting parameters whilst deploying web applications to both Azure or an on-premise IIS Server. Every project is different, and sometimes you need to be able to inject a step into the Web Deploy package creation process to complete some extra step. This can be done by adding a target to the .csproj project file. The following example shows how you could sign the assemblies before the Web Deploy package is created. ...

The Issue We are running our SonarQube instance as an Azure hosted Docker container. Over the past few weeks we have been seeing intermittent occurrences of the ProjectFileIndexer exception during the SonarQube analysis step in our Azure DevOps pipelines. ##[error]java.lang.IllegalStateException: Unable to load component class org.sonar.scanner.scan.filesystem.ProjectFileIndexer When I looked closer at the exception stack, I could see at the bottom there was always a timeout error when trying to access the project.protobuf file from SonarQube. ...

Background As I have blogged previously, we run a SnipeIT instance to manage our IT assets, hosted in Azure using Docker. This has been working well for us for the past year, but recently we have noticed that the system has become very slow to respond. Looking on the Azure portal, we can see that around the 15th of October the web app’s response times have gone from milliseconds to 10s of seconds ...

Background If you are using staged deployment in Azure DevOps, you will probably have multiple Azure Service Connections. So, it makes sense that you might want to use a Service Connection name that is stored in a variable group as a parameter to a templated YAML pipeline. # the build pipeline stages: - stage: UAT jobs: - deployment: ARM_Provisioning timeoutInMinutes: 0 environment: 'Staging' variables: - group: UAT pool: vmImage: 'windows-latest' strategy: runOnce: deploy: steps: - template: YAMLTemplates\ProvisionUsingARM.yml parameters: AzureResourceGroup: $(AzureResourceGroup) AzureServiceConnection: $(AzureServiceConnection) - stage: PROD jobs: - deployment: ARM_Provisioning timeoutInMinutes: 0 environment: 'Staging' variables: - group: PROD pool: vmImage: 'windows-latest' strategy: runOnce: deploy: steps: - template: YAMLTemplates\ProvisionUsingARM.yml parameters: AzureResourceGroup: $(AzureResourceGroup) AzureServiceConnection: $(AzureServiceConnection) With a template YAMLTemplates\ProvisionUsingARM.yml that uses the AzureServiceConnection variable ...

One of the most useful, and it seems relatively unknown, features in the GitHub web UI is the ability to edit multiple files in the UI and commit them in a single commit. This is done by loading VS Code in the browser when in the code view by pressing . (the full stop) The reason I find this so useful is that it allows me to make a series of small related changes to a project without having to clone the repository or using a CodeSpace, very useful when editing the related YAML files of reusable workflows in GitHub Actions. ...

This is is one of those posts I write so I remember how to do something in the future. Background I recently had a need to generate many Visual Studio SQL Database Projects from existing databases. Being a good ’lazy developer’ I wanted to do this from the command line so I could automate the process, but it took me far to long to work out how The Manual Way If you only have one database to import you can do this manually by using the Import option in Visual Studio for an individual SQL Database Project. ...

I have blogged in the past about Caching NVD Vulnerability Dependency data on hosted Azure DevOps Pipeline agents. Using the cache is a great way to speed up slow builds. However, today I was surprised to find I was getting cache misses on my pipeline, even though I was sure the cache should have been hit. There are rules over how the cache is used: The cache is specific to a pipeline definition, so there is no sharing of the cache between pipeline definitions The cache is only created if the pipeline is successful (running the post run tasks) The cache only lasts 7 days but what I had not realised was the cache is also specific to the branch in a not so obvious way. My pipeline was triggered off a PR, so the cache was being created on the ‘branch’ PR #123. This was working as expected, all runs of the PR triggered build used the cache after the initial run. However, if I manually triggered pipeline run of the same branch as the PR was using, there was a cache miss. ...

Background Programmatic connection to Azure DevOps cannot be done with your Active Directory credentials. This is because this involves a dialog being shown, and these days usually an MFA check too. Historically, the solution to this problem was to enable Alternate Credentials, which could be passed as username and password, without the dialog being shown. However, the use of these has been deprecated since 2020, and they have been completely removed since Jan 2024. ...

It is a major effort, often unfortunately ignored, keeping the dependencies in an open source project up to date. This was highlighted in Jesse Houwing’s post on the state of the Azure DevOps Marketplace. Since reading this I have made much more of an effort to keep my Azure DevOps Extensions up to date. Dependabot generated PRs have been a great help in this regard. Creating PRs for vulnerabilities and out of date dependencies. ...