Hi there, I am Alastair 👋

An example Actions workflow thet shows how to deploy to a test environment on every commit, and then give you a button to push to promote it into a production environment, with different variables in each environment

How did I migrate this blog from fully featured open source CMS Ghost to a static site using Hugo (and save some cash in the process)?

Should you specify absolute expiry of a cache item from the current time or from the current time in the UTC time zone? The answer may not be what you expect.

LazyCache is a library that makes it easy for developers to add in-memory caching to dotnet apps. Version 2 is a major rewrite to change from the .Net Framework 4.5 to Netstandard 2.0, and is now available from nuget.org/packages/LazyCache. Getting started Install from nuget: dotnet add package LazyCache --version 2.0.0 And then cache object that are slow or expensive to produce: IAppCache cache = new CachingService(); Func<ComplexObjects> complexObjectFactory = () => methodThatTakesTimeOrResources(); ComplexObjects cachedResults = cache....

If you use logging in your application code (and you should) then it would be nice if all that logging info appeared in your unit tests. If you use dotnet core and the default Microsoft.Extensions.Logging then logs will not automatically appear. Unfortunately the default Debug and Console loggers in the Microsoft.Extensions.Logging family do not flush to standard out quick enough for test frameworks like NUnit to pick up the output because they flush on a background thread for performance....

If you have to maintain a farm of build servers it can be a pain to keep them updated will the latest versions of all the tools needed, and if you have a few servers you will have scripts to automate this. Normally chocolatey does a great job of this for me, however scripted update of VS build tools using chocolatey does not seem to work. The MS installer cli docs for this stuff are fairly comprehensive, but lacking coverage of just the build tool update scenario at the moment....

Building high quality end to end acceptance tests suites is hard, and creating API stubs (aka mock servers) can be surprisingly time consuming. WireMock.net can help speed this up. E2E testing is hard End to end testing is hard for many reasons, but I think one of the most common is that the developers under estimate how much time to allow for it and then rush the job. Most E2E test harnesess I have worked on, (including several I wrote myself!...

Build scripts for .net are always a bit painful, and Microsoft has not made it easy over the years as every release they change the paths. For 2017 it is even worse and it depends on the edition so they want you to use vswhere.exe to locate the installed version(s) of msbuild. I find the following bit of Powershell to be far more portable and reliable. Function Find-MsBuild([int] $MaxVersion = 2017) { $agentPath = "$Env:programfiles (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15....

Every time Microsoft releases some build tooling it feels like they forget lots of us use it to build websites. And we do this on build servers that do not have Visual Studio installed using scripts. We even dare to have created websites with old versions of Visual Studio and upgrade them when a new one comes out. I often find that these scripted builds fail on build servers because they are missing Microsoft....

A few quick tips I have picked up working with UmbracoCMS that might help you out when things go wrong. Ensure you can login to the database directly using any username and password in the web.config file. Whilst this is obvious and true for any website, Umbraco has a habit of swallowing these errors at times like upgrades leading to some missleading error hunting. Check the logs in ~\App_Data\Logs. By default each site logs to a local app data folder....