Posts

The Problem Due to recent changes at NIST and the way they host the NVD DB the dependency-check/DependencyCheck tool that underpins the Azure DevOps OWASP Dependency Check is struggling to download the vulnerabilities DB. This is all discussed in this support thread. The root cause of the problems is a mixture of many updates to the NVD DB, increasing the download size, and tighter throttling of the API. The net-effect of this is that download the NVD DB now takes hours, not minutes, with many timeouts and retries. ...

The Problem I have posted in the past about caching the National Vulnerability Database (NVD) used by Jeremy Long’s DependencyCheck tool via the associated Azure DevOps task. Today I had an issue that on one pipeline the Azure DevOps task was reporting the following error Starting: Dependency Check ============================================================================== Task : OWASP Dependency Check Description : Dependency Check is a Software Composition Analysis (SCA) tool that attempts to detect publicly disclosed vulnerabilities contained within a project's dependencies. Version : 6.3.0 Author : Dependency Check Help : [More Information](https://github.com/dependency-check/azuredevops) ============================================================================== Starting Dependency Check... Setting report directory to D:\a\1\TestResults\dependency-check Creating report directory at D:\a\1\TestResults\dependency-check Downloading Dependency Check latest installer from GitHub.. Cannot read properties of undefined (reading 'find') ##[error]Cannot read properties of undefined (reading 'find') ##[error]Unhandled error condition detected. Ending Dependency Check... Finishing: Dependency Check The Analysis I tried a few things: ...

The Problem I recently came across a problem with a complex BitTalk solution being built in an Azure DevOps Pipeline. It had been working fine, but it started to fail with error related to failing to copy built DLLs from the obj folder to the bin folder because it said the files were in use by MSBuild. The Analysis I tried a few things, all to little effect: Restarted the self-hosted Azure DevOps Pipeline agent, in case they were holding a lock on a file Delete the builds _work\<number> folder, in case it had become corrupted Re-ran the build against the last Git commit, this worked so at least proving the issue was in a code change and not something to do with the build agent VM. Built the solution locally on a development PC via Visual Studio, it built OK Built the solution using the same, or at least similar (removing the Azure DevOps specific flags) MSBuild command locally on a development PC, and this time I got the same error. So the issue was a recent code changes, but only showed up when using MSBuild directly, but not when letting Visual Studio orchestrate the build process. ...

Whilst at DDD South West I did a very enjoyable panel podcast recording for Dan Clarke’s Unhandled Exception podcast on the subject of the impact of AI on software development. I am please to say that the recording of the panel has just been published. So why not have a listen to it, or any of Dan’s back catalog

Thanks to everyone who came to my session ‘Why don’t people seem to be able to diagnose problems these days?` at yesterday’s DDD South West. I don’t believe there is a recording of this session from any event where I have delivered it, but you can find a copy of my slides, with all my other presentations, in the repo rfennell/Presentations Thanks again to the DDD South West organisers for putting on another great event. ...

Background I have posted in the past on how we manage Azure DevOps Pipeline Agents with Packer and Lability. Whilst deploying a new agent I hit a interesting problem, the issue was completely a ‘UTS’ (user too stupid) error, but the way it was surfaced was I think interesting. The Problem My script built and deployed a new Hyper-V VM, setting up the OS, adding disks and installing the Azure DevOps Pipeline agent. However, the agent did not get registered with Azure DevOps. On checking, I could see that the new VM had a configured network adaptor, but no network connection ...

Background My post-op chemotherapy treatment for my adrenal cancer meant I was struggling to get any fitness, so in 2019 I bought a Ribble CGR-ALe ebike based around the Mahle X35 system. It was in fact pre-ordered prior to the bike’s initial release by Ribble. This bike served me well, getting me out and about before any fitness returned. Since getting fit again, it has also proved useful for my 20KM each-way commute. Allowing me to avoid the traffic jams but still get to work without getting too hot and sweaty. ...

Background We have a few non-critical systems running as single instance Docker containers hosted on Azure WebApps. On these systems we have started to see the warning Your app is configured with Docker Compose, which is set to retire on March 31, 2027. For multi-container support, please update your app to support sidecar containers. So, best to get ahead of the game I looked into how to update them, factoring in that ours are all BICEP defined and deployed with Azure DevOps Pipelines ...

The Problem I recently had a customer who’s Azure DevOps Pipelines BizTalk 2020 build had suddenly started to fail. They said they had not altered their BizTalk solution, or their build process. The Analysis Turns out the issue was that the operating system on the VM that hosts their self-hosted Azure DevOps agent had had a update. This update it seems had updated the version of MSBUILD shipped with Windows. Making it the newest version, newer than the one shipped with Visual Studio 2019. ...

The Problem Today I was upgrading our self hosted Delinea Secret Server from 11.9.x to 12.0.x. These upgrades are usually an easy process, all achieved within the Secret Server web UI, but not today. The upgrade proceeded as normal, downloading the new package, updating the DB schema and updating the binaries, but then it stopped. It did not move onto the next step. The Analysis I remoted onto our Windows server hosting our Secret Server instance and via Internet Information Service Manager launched the Secret Server instance via the URL http://localhost. This showed the error ...