xUnit.net: two package lines, two test platforms, one repository

xunit and xunit.v3 are different packages

The most common way to get this wrong is to assume there is one package. There are four, and two of them are different major lines of the same framework:

| Package | Latest stable | CI builds come from | | --- | --- | --- | | `xunit.v3` | NuGet | the `main` ref | | `xunit` | NuGet | a `v2` ref | | `xunit.analyzers` | NuGet | the `main` ref | | `xunit.runner.visualstudio` | NuGet | the `main` ref |

The third column is read off the CI badge links in the README's latest builds table, and it says something useful: the `xunit` package is still being built and published from a v2 ref while everything else builds from `main`. So one repository carries two supported major lines and publishes CI artefacts for both.

For an adopter the consequence is concrete. `xunit` is the older line with the older requirements, `xunit.v3` is the current one, and the release tags follow the same split with a `v3-` prefix. Adding the wrong package reference is not a version bump, it is a different framework with a different floor.

The analyzers and the Visual Studio runner are separate packages whose build status badges point at the separate xunit/xunit.analyzers and xunit/visualstudio.xunit repositories, which is why an upgrade touches more than one reference in your project file.

Version 3 raised the floor, not the ceiling

The stated support for v3 is .NET 8.0 or later, and .NET Framework 4.7.2 or later. That is the whole compatibility statement, and it is short enough to check against your own project before you plan an upgrade.

Two readings of it matter in practice. On modern .NET, v3 is straightforward. On .NET Framework, 4.7.2 is an old but still deployed target, so a framework team with a large .NET Framework estate is the group that has to read this line twice.

For anything below those versions, v3 is not an option and the v2 line is where the project stays. Nothing in the README promises an end to v2 support, and the CI builds for the `xunit` package suggest it is still receiving attention rather than being frozen.

The language story is wider than the runtime story. The framework covers C#, F# and Visual Basic. That has not changed with the v3 floor.

The runner is decoupled from the IDE

The list of environments is long enough to be the actual design statement: the .NET SDK command line tools, Visual Studio, Visual Studio Code, JetBrains Rider, NCrunch, and any development environment compatible with Microsoft Testing Platform or VSTest.

The last clause is the mechanism. Rather than shipping its own runner for each host, the framework targets the two test platform contracts the .NET ecosystem has, so an editor that speaks either one can discover and run the tests. That is why a test written once shows up in the Rider test window, in the Visual Studio test explorer and in a `dotnet test` invocation on a build agent.

The consequence for a team is that the editor is not the integration point, which cuts both ways. You are not locked into one IDE, and you are also not getting IDE specific features. Anything a host cannot express through the platform contract simply is not there, and the answer to a missing test window feature is usually the host's support for the platform rather than xUnit itself.

The `xunit.runner.visualstudio` package is the piece that carries the Visual Studio side, and it is versioned separately from the framework.

Stable from NuGet, CI from a feed with a login

The latest builds table has a column for the latest stable package and a column for the latest CI package, and they come from different places. Stable builds are on NuGet. CI builds are published through a feed service, and the README points at a package search page there for the complete CI package lists, noting that a free login is required.

That is a small operational detail with a real consequence. If you want to try tomorrow's build against a problem that today's stable release does not fix, you are signing up for an account on a third party feed and pointing your restore at it. On a locked down build agent, where feeds are usually allowlisted, that is a change to your pipeline configuration rather than a version bump.

The same split shows in the tags. The three most recent releases are `v3-4.0.0` on 2026-08-15, `v3-4.0.1` on 2026-09-12 and `v3-4.0.2` on 2026-10-09, so the 4.0 line stabilised in August and took patches in September and October.

The build status column links to per-package badges, which means you can check whether the line you depend on is green before you decide to move.

The assertion library is a separate contribution surface

Contributing to the framework and contributing to the assertions are two different workflows, and the README says so. Framework contributions follow the contributing guide, which lives in a separate `xunit/.github` repository rather than in this one.

Assertions are the more complicated path. They go to the `assert.xunit` project, which carries its own suggested contribution workflow, and the README explains why in one clause: the code is spread across two GitHub repositories, so the workflow is slightly more complex.

That is a practical warning for anyone who arrives expecting a single repository to contribute to. Assertion changes, new matchers, changes to failure message formatting: those are reviewed and landed in a different place from a change to discovery or execution, and the review surface is split with them.

A PowerShell build over a pinned SDK and an XML solution

The top level tree describes a build that is driven from a script rather than from an IDE:

global.json
version.json
xunit.slnx
build.ps1
.gitmodules

`global.json` pins the .NET SDK the repository builds against, which is the mechanism that keeps a contributor's machine and the build agent on the same toolchain. `xunit.slnx` is the XML form of a solution file, and there are also a `build` file next to `build.ps1`, plus `tools/` and `docfx/` directories.

`.gitmodules` at the root means the repository pulls in submodules, so a plain clone is not the whole tree.

`BUILDING.md` is the documented entry point for building the source, and it is a separate file from the README, which is the right split for a repository of this size. The editor and assistant configuration is declared too, with `.editorconfig`, `.vscode/`, `.copilotignore` and `.cursorignore` alongside an `ai.txt` file at the root.

Apache 2 inside the .NET Foundation

xUnit.net is part of the .NET Foundation and operates under its code of conduct. It is licensed under Apache 2, which the README identifies as an OSI approved licence, and it is governed by a Project Lead rather than by an individual maintainer.

For a test framework that is an unusual position, and it has a practical effect. There is a named lead responsible for direction, and the foundation provides the conduct and governance structure around it.

Funding runs through GitHub Sponsors, with the README asking for sponsorship rather than describing a commercial offering. There is no paid tier, no closed runner and no feature gate: the framework, the analyzers and the Visual Studio runner are all open.

The repository is not archived, and the last push is dated 2026-10-28, a few weeks after the v3 4.0.2 tag. For a library as established as this one, that combination, an Apache 2 licence, foundation governance and a current commit date, is the practical answer to whether the project is still moving.

Editorial conclusion

xUnit.net fits a .NET team that wants one test framework across the SDK, Visual Studio, Rider and CI, and that can live with the .NET 8 floor if it intends to move to v3. It does not fit a project still on an older runtime that intends to stay there, since v3 will not load there and the v2 line is the older major. Verify two things before you upgrade: which package you actually reference, because `xunit` and `xunit.v3` are different packages with different floors, and whether your CI can consume a non stable build, since the CI packages come from a separate feed that requires a login.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. xunit/xunit on GitHub