Andy Butland

Found a use case for a feature of the .NET mocking framework Moq that may not be that well known, and was new to me at least. I had a method under test that - via a number of overloaded extension methods - called an underlying method in the Umbraco CMS. The details aren't really important, but specifically it was the method GetImageUrl on IImageUrlGenerator that I was mocking to return a known output. I was then testing how my method used that result it in it's processing. I could see the method failing when I had a setup like this: But passed with this: So clearly we weren't passing in the Height parameter that I was expecting. One way to solve this would be to get the Umbraco code locally and step into it, but I found another way that I read about on this closed issue for the Moq library. It provides a means of capturing the parameters passed to a mocked method, and then establishing what they are via a breakpoint or logging. That revealed that so

One of the projects I currently work on consists of a few components - an API, a worker process, a couple of web applications and a serverless functions app - all of which are deployed to Azure using infrastrure as code defined as Terraform resources . We have recently been upgrading it from .NET 6 to .NET 8 and hit an issue when we tried to update the framework definition of the Azure app service resources defined in Terraform. The attribute in question only accepted up to .NET 6. The reason is that the resource we were using - azurerm_app_service - is now deprecated and replaced with azurerm_windows_web_app (or azurerm_linux_web_app ). It was a similar case for the app service plan ( azurerm_app_service_plan replaced with azurerm_service_plan ) and the functions app ( azurerm_function_app replaced with azurerm_windows_function_app ). Naively, my first thought was to just update our infrastructure configuration to use the newer resources, and deploy that update. However, don