Just an environment variable away from sleep
It’s a quarter past midnight, you should be going to sleep, but there’s that one unit test that fails only on GitHub Action macOS build agent — it’s mocking you so you stay awake just a bit longer…
You bring out you Mac and execute tests, fortunately we can reproduce — the test fails on your machine too! A quick inspection of test output informs you that error only occurs on .NET Core.
Unfortunately, today neither VS Mac nor VSCode for some reason is your friend, solutions won’t build, tests aren’t found, break points aren’t hit and so on.
Probably not their fault at all, more likely a case of complex multi target solution, having preview versions and just being too tired.
Fortunately, as the .NET CLI “dotnet test” command executed by the build script compiled and executed the tests, one could leave the VS Mac/Code IDE tooling debugging for another day and trigger debugging from the command line.
This is achieved by setting the environment variable VSTEST_HOST_DEBUG to 1
Bash:
export VSTEST_HOST_DEBUG=1PowerShell:
$env:VSTEST_HOST_DEBUG=1
Now when executing the test (specifying only the framework I want to test)
dotnet test My.Tests.csproj — framework=netcoreapp3.0It’ll will pause and wait for a debugger to attach.
Microsoft (R) Test Execution Command Line Tool Version 16.3.0
Copyright (c) Microsoft Corporation. All rights reserved.Starting test execution, please wait...A total of 1 test files matched the specified pattern.
Host debugging is enabled. Please attach debugger to testhost process to continue.
Process Id: 32723, Name: dotnet
Waiting for debugger attach…
Process Id: 32723, Name: dotnet
And I could now attach to process both from VS Mac
and VS Code
Which allowed me to set break points, inspect variables and step through code, even though the IDEs themselves for some reason couldn’t compile and execute the tests.
Fairly quickly found the issue added a commit and builds were green and I could go to sleep.
Sometimes you just want to attack the problem and not debug tooling, then attacking the problem from another direction might get you there quicker, today it was setting VSTEST_HOST_DEBUG to 1.
