AwesomeAssertions and the Apache 2.0 fork of FluentAssertions

The licence change that split the project in two

FluentAssertions was licensed under Apache 2.0 up to version 7.x. Later versions introduced licensing changes that could mean fees for developers, and that single fact explains this fork. AwesomeAssertions exists to keep the assertion library available under the terms it originally shipped with, governed by a group of named maintainers rather than one commercial owner.

The point is less about new features than about continuity. Assertion helpers sit inside test projects that tend to live for years, so a licence shift upstream is not a one time migration expense but a recurring one, and it arrives at the worst possible moment, in the middle of a sprint, when nothing about the code has changed. The project describes itself plainly as a fork of FluentAssertions controlled by the community, and the project is not affiliated with or endorsed by the authors of FluentAssertions.

What you get in practice is a NuGet package named AwesomeAssertions that behaves like the library people already know, published from a repository whose default branch is main and whose homepage is awesomeassertions.org.

Why version 8 could be shipped before the upstream licence change landed

The FAQ in the project description answers the question that any reasonable reader asks first: how could a fork publish version 8 with changes that look almost identical, if upstream version 8 already sits under a commercial licence? The answer is timing. The upstream licence change was made at the final stage of the version 8 release, and any commit made before that point was free to use, because licences cannot be applied retroactively.

The explanation goes further. Commits added to the branch while it was under Apache 2.0 remain under Apache 2.0, so every commit before the upstream change at commit df7e9bf can legally be used under the Apache 2.0 terms. That gives the fork a defensible legal basis for the code it carries, rather than a hopeful reading of the original grant.

This is also the reason the project can promise continuity of terms. The stated policy is that the licence will never change, not even to MIT, and that only the original Apache 2.0 licence will be maintained. For engineers asked to justify a dependency choice to legal reviewers, that is the sentence that matters.

Renovate rewrites the package reference without touching your code

The migration path is deliberately boring. Rather than asking developers to rename namespaces across thousands of assertion lines, the project leans on Renovate Bot. Add one rule to your renovate.json and Renovate opens pull requests that replace the FluentAssertions package with AwesomeAssertions wherever it appears in a solution.

The rule in the project description is the whole configuration. The replacement version is pinned at 7.0.0, which is worth noticing: the automatic swap deliberately targets the Apache 2.0 era of the upstream library rather than the newer commercial line.

{
  "packageRules": [
    {
      "matchPackageNames": ["FluentAssertions"],
      "replacementName": "AwesomeAssertions",
      "replacementVersion": "7.0.0"
    }
  ]
}

For repositories that do not run Renovate, a PowerShell script is linked from the project description for doing the same replacement by hand. Either way the unit of work is a package reference, not a rewrite of test suites, which is the main practical argument for taking the fork at all.

Building the source needs four .NET SDKs on one machine

Contributors should know before cloning that this is a wide build, not a single target framework project. The instructions call for Visual Studio 2026 18.0 or later, or JetBrains Rider 2025.3, together with the Build Tools 2022 including the Universal Windows Platform build tools. On top of that you need the .NET Framework 4.7 SDK, the .NET 6.0 SDK, the .NET 8.0 SDK and the .NET 10.0 SDK installed at the same time.

The current minimum required version is recorded in global.json, so the file is the right place to look for the exact floor rather than guessing from the README. The repository root also carries build.cmd, build.ps1 and build.sh, an AwesomeAssertions.slnx solution file, Directory.Build.props for shared build settings and GitVersion.yml for release numbering.

For a contributor on macOS or Linux, that machine setup is the real entry cost. There is no lighter documented path in the project, and the answer to "can I just build one project" is that the SDK set is not optional.

Approval.Tests stop the public API from moving quietly

The Approval.Tests set is a special group of tests that use the Verify project to detect whether a change has altered the public API of the library. Snapshot comparison of the public surface is a blunt but effective guard: a rename or a removed overload shows up as a diff rather than as a broken build somewhere downstream.

When the diff is intended, the workflow offers two scripts, AcceptApiChanges.ps1 and AcceptApiChanges.sh, which write the new expectation as the accepted baseline. On Rider, the Verify Support plug-in can compare and accept changes from inside the IDE, and the project points contributors at the contribution guidelines for the wider process.

For a maintainer this is a speed bump by design, since every accepted API change becomes a permanent obligation for every downstream consumer. For a user of the package it is reassurance: the surface you call is checked on every change set, and the version you depend on is not going to lose a method in a patch release without someone noticing.

A small maintainer group and a steady release line

Governance is explicit rather than implied. The FAQ names the current maintainers: @cbersch, @IT-VBFK, @jcfnomada, @jupjohn, @lg2de and @ScarletKuro. The project also credits the original FluentAssertions authors and more than 200 contributors, and states that FluentAssertions is a trademark of its respective owners.

The release record shows three tagged versions in 2026 alone: 9.4.0 on 2026-02-18, 9.5.0 on 2026-07-19 and 9.6.0 on 2026-08-20. The last push to the repository was on 2026-10-07, so the project is being worked on rather than left as a published archive.

Documentation is hosted separately on awesomeassertions.org, with an introduction, an extensibility guide, support information and a tips and tricks section, and the repository root carries a docs directory plus a package.json that only wires up the cspell check over the documentation files.

Where the fork is the wrong tool

The honest limits are worth stating. First, the fork is a snapshot of upstream work carried forward under Apache 2.0; anything the upstream project produces after its licence change does not arrive here, so a team that needs a feature that only exists in the newer commercial releases will not find it in the package.

Second, the automatic replacement is pinned to a specific replacement version in the Renovate rule, and it only works in repositories that already run Renovate. Elsewhere the migration is a manual script run, and in a solution with many test projects that is real work even if each change is small.

Third, the build environment is demanding for contributors. Four SDKs, a specific IDE generation and a platform build tools requirement make a first contribution slower than it would be in a smaller library. Fourth, the project states plainly that it is not affiliated with the FluentAssertions authors, so there is no vendor to escalate an issue to, and the legal disclaimer keeps that line in the open. A team that needs a single accountable supplier for its assertion library will not get one here.

Editorial conclusion

Teams that want the fluent assertion API and Apache 2.0 terms can move to AwesomeAssertions, but they should first check global.json for the required SDKs, confirm their current FluentAssertions version is still on the Apache 2.0 line, and be ready to run the API approval scripts when they touch the public surface. Teams that depend on commercial-only upstream features, or that need a single vendor supported channel, will find less here than they need.

Frequently asked questions

Official sources

1. AwesomeAssertions/AwesomeAssertions on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases