The Daily Parker

Politics, Weather, Photography, and the Dog

Azure DevOps gotcha upgrading to .NET 5

Also known as: read all error messages carefully.

I've just spent about 90 minutes debugging an Azure DevOps pipeline after upgrading from .NET Core 3.1 to .NET 5 RC2. Everything compiled OK, all tests ran locally, but the Test step of my pipeline failed with this error message:

##[error]Unable to find D:\a\1\s\ProjectName.Tests\bin\Debug\net5.0\ref\ProjectName.Tests.deps.json.
Make sure test project has a nuget reference of package "Microsoft.NET.Test.Sdk".

The test step had this Test Files configuration:


I'll save you all the steps I went through to determine that the .NET 5 build step only copied .dlls into the ref folder, without copying anything else (like the dependencies definition file). The solution turned out to be adding one line to the configuration:


Excluding the ref folder fixed it. And I hope this post saves someone else 90 minutes of debugging.

Simple Azure management using CloudMonix

We've been using CloudMonix for a while to manage and monitor our Microsoft Azure assets. By "we" I mean both Inner Drive Technology (home of The Daily Parker) and Holden (my day job).

CloudMonix recently added a new feature that automates virtual machine (VM) management. See, Microsoft charges for VMs by the hour. So if you have a VM that is only used at specific times, you're wasting money by having it run all the time.

A great example: Our continuous integration (CI) server, which builds and tests our (Holden's) applications every time a developer publishes a change to our master Git repository. Typically no one is making changes outside of business hours. So most of the time, the CI server just sits there, doing nothing.

Last week I configured CloudMonix to shut down our CI server every night at 6pm and wake it up at 7am the next morning. I only made two minor errors.

First, shutting down a VM in Azure makes its IP address evaporate, which screwed up some of the tests that connect to Salesforce. Second, the CI server runs a weekly build and smoke test early Monday morning, so we know first thing that the build is OK for the week. It was running at 4:15; I had to move it to 7:15. And all is good.