What it is
Ubuntu Test Runner is a purpose-built Ubuntu 24.04 Docker image for remote .NET test execution and debugging. It provides a Linux-aligned test target with current .NET LTS and STS SDKs, preview builds for forward-looking validation, and vsdbg for remote debugging when failures need inspection inside the container.
There is intentionally no dedicated source repository for this Tool. Its public product surface is the Docker Hub image and its documentation.
Why choose it
Use this Tool when test execution should match a Linux deployment target more closely than a developer workstation can. It helps reduce environment drift between local development, remote test execution, and CI by giving teams one reusable Ubuntu runner image.
It is especially useful for multi-targeted .NET repositories. A single Microsoft SDK image is often right for one .NET major. A repository that needs a wider target-framework matrix can use a Codebelt multi-SDK runner so restore, build, test, and debugging happen in one compatible remote environment.
Tag strategy
The combined image includes the currently supported LTS and STS SDK lines, with the active Preview SDK added when one is available. This keeps one runner useful for supported target frameworks while letting teams check compatibility with the next .NET release. The image build accepts a list of exact SDK versions, so Docker Hub can publish both single-SDK images and combined images for multi-targeted repositories. Microsoft's support policy identifies the current release channels.
Docker Hub publishes floating major and major/minor aliases such as 8 and 8.0, alongside fully versioned tags such as 8.0.425. Combined images also have floating aliases such as 8-9-10-11 and 8.0-9.0-10.0-11.0, plus a fully versioned tag such as 8.0.425-9.0.318-10.0.401-11.0.100-rc.1. The shorter aliases follow refreshed SDK patches for convenient updates; fully versioned tags identify the SDK versions in the image. Hyphens also appear inside prerelease labels such as rc.1, so splitting the combined tag at every hyphen would make the SDK list ambiguous.
The version badge summarizes a combined tag with its highest stable, fully versioned SDK. For the current example above, that is v10.0.401: the .NET 11 release candidate remains available for forward-compatibility checks, while the badge points to the latest stable LTS or STS SDK installed. Docker Hub retains the full tag for selecting the exact SDK set.
What it gives you
- Ubuntu 24.04 as the Linux execution environment.
- Current .NET LTS and STS SDKs, with preview SDKs available for compatibility checks.
vsdbginstalled for remote debugging.- A reusable Docker image for Visual Studio remote testing, local container test runs, and CI-aligned troubleshooting.
- A practical default for Codebelt
testenvironments.jsonDocker entries when the repository needs Linux remote tests.
How it fits the SDLC
Ubuntu Test Runner belongs in the testing and delivery path. It helps prove that tests run where the software is expected to run, and it gives debugging a predictable Linux container instead of an ad-hoc workstation setup.
It pairs strongly with the .NET Remote Testing skill. The Tool is the runtime environment. The Skill selects or derives the remote test environment from repository evidence, stages the source, runs the suite, classifies failures, and cleans up. .NET Test remains relevant when the test host itself needs to be modernized before remote execution is meaningful.
Getting started
Install and start Docker Desktop, then add a file named testenvironments.json to the root of your solution. This example registers the Ubuntu Test Runner image as a Docker environment for Visual Studio remote testing:
{
"version": "1",
"environments": [
{
"name": "Docker-Ubuntu",
"type": "docker",
"dockerImage": "codebeltnet/ubuntu-testrunner:10"
}
]
}
If the image is not available locally yet, pull it with docker pull codebeltnet/ubuntu-testrunner:10. In Test Explorer, select Docker-Ubuntu from the environment menu to discover and run tests in the container. Keep Docker Desktop running, confirm that the image includes the SDK and dependencies your tests require, and use Output > Tests to monitor the connection. See Microsoft's Visual Studio remote testing guide for setup requirements and connection guidance.
Choose the tag that matches the SDK set your repository needs. For multi-SDK validation, prefer the documented combined SDK tags on Docker Hub rather than inventing a custom image for each target-framework combination.