CI for Open Source Dotnet

Azure Devops

First time around I abandoned this after spending far too much time meddling with it, it may just be me but I didn’t like it and the whole debugging cycle felt slow and clumky. Second time around the process seems even more clunky than I remember it and it’s not always obvious how to get back to where you just were. In addition the error messages are completely unhelpful. Thankfully most of mine were syntax errors or lower/upper case errors and they got resolved after a few attempts.

- master
vmImage: ubuntu-latest
buildConfiguration: 'Release'
- script: dotnet build -c $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
- script: dotnet test -c $(buildConfiguration)


This was the one I was most interested in as it allowed the CI to run on a Windows VM. Unfortunately I struggled with this one first time round, in particular as it doesn’t integrate well with Github in that we couldn’t see build/test progress.

version: 1.0.{build}
image: Visual Studio 2022
configuration: Release
- cmd: dotnet restore
project: NLC.Library.sln
verbosity: minimal


Travis used to have two sites, one for open source and one for paid customers. First time round I only looked at the open source on. Now they both use the same site. The free plan is limited to what appears to be a generous amount of credit and allows unlimited users! Unfortunately it appears that Travis has been subject to abuse so it now requires a credit card which I don’t have. Unfortunately this meant that I couldn’t return to the system.

language: csharp
# solution is optional and results in a restore
solution: NLC.Library.sln
# mono only needed for paket
mono: latest
# attempt to use linux and mac
- linux
- osx
osx_image: latest# dotnet version can be more specific but that is handled by global.json# specific version of sdk to prevent mac issuesdotnet: 3.1.403 # 404 not on travis yetbefore_install:
- if [ "$TRAVIS_OS_NAME" = "osx" ]; then brew update ; fi
# needed for tests
# dotnet: 2.1
- dotnet build src/NLC.Library.csproj -c Release
- dotnet test tests/NLC.Library.tests.csproj -c Release


The first thing to note here is that Free and Open Source project are allowed an extremely generous amount of credits per month. I really struggled with this one. It uses some terminology that’s new to me e.g. Orbs — which are actually some modular YAML which is quite a nice idea as it can be re used, though the other side of that is that it conceals complexity. The first issue I came up against was YAML — my spacing was slightly out in a few places, after a few goes that was fixed. Then my library refused to build whatever I tried. Further investigation indicated that .NET 6 wasn’t available.

version: 2.1orbs:
windows: circleci/windows@2.4
description: 'Setup and run tests'
name: windows/default
- checkout
- run:
name: 'Install dependencies'
command: dotnet.exe restore
- run:
name: 'Run tests'
command: dotnet test
description: 'Build app'
name: windows/default
- checkout
- run:
name: 'Build app'
command: dotnet.exe build -c Release
- test
- build:
- test

Github Workflows

In some ways this is a no brainer as the code is hosted on Github. For me a nice feature of the original was that it was simple to add a Mac OS pipeline as I also develop on a Mac. This is one of those that was relatively simple to setup the first time around as it is quite well documented for simple cases.

# this is our main Windows based build
name: .NET Core
branches: [ master ]
branches: [ master ]
runs-on: ${{ matrix.os }}
os: [ windows-latest, macos-latest, ubuntu-latest ]
- dotnet-version: '6.0.101'
tfm: 'net6.0'

- uses: actions/checkout@v3
- name: Setup .NET Core ${{ matrix.os }}
uses: actions/setup-dotnet@v1.7.2
dotnet-version: ${{ matrix.dotnet-version }}
- name: Display dotnet version
run: dotnet --version
- name: Install dependencies
run: dotnet restore -p:TargetFramework=${{ matrix.tfm }}
- name: Build
run: dotnet build --configuration Release --no-restore
- name: Test
run: dotnet test --no-restore --verbosity normal -f=${{ matrix.tfm }}


I was a little surprised by the results here. I didn’t have good memories of Azure Devops but this time around it was much better. I was disappointed about Travis as this had worked for some time. For me the standout was AppVeyor — the configuration was simple, you don’t need to worry about spaces in the right place or whether you have used upper or lower case — for someone who rarely uses this stuff, that can be quite significant.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Steve Ellwood

Steve Ellwood

Senior Integrations Officer at Doncaster Council Any views expressed are entirely my own.