Table of Contents

Core Framework v3 1.1.0 2025 February 7

Today, we're shipping three new releases:

  • xUnit.net Core Framework v3 1.1.0
  • xUnit.net Analyzers 1.20.0(release notes)
  • xUnit.net Visual Studio adapter 3.0.2 (release notes)

It's been 1 month since the release of 1.0.1.

As always, we'd like to thank all the users who contributed to the success of xUnit.net through usage, feedback, and code. 🎉

Release Notes

These release notes are a list of changes from 1.0.1 to 1.1.0.

Core Framework

  • Attachments (added via TestContext.Current.AddAttachment) are now being reported as "test node file artifacts" in Microsoft Testing Platform mode. You can see this in the output of dotnet test, which will list all the artifacts when the test run is complete.

    Note: Attachments do not show up in Test Explorer when using Microsoft Testing Platform mode. We have opened an issue to get clarity as to exactly whether this is a bug on our part or in Test Explorer. Attachments do show up when running in Test Explorer in VSTest mode, so we strongly recommend you disable Microsoft Testing Platform mode in Test Explorer if you need access to attachments until the issue can be resolved.

  • BUG: We have fixed an issue where support for serializing objects which implement IFormattable and IParsable<TSelf> would not work if the Parse method is hidden by an intermediate interface. Now we will try to call TryParse first, and then fall back to Parse. At least one of these methods must be public on the class being serialized; hiding them both is not supported. xunit/xunit#3141

  • BUG: We have fixed an issue where throwing TaskCanceledException (directly or indirectly, typically by way of a cancelled CancellationToken) would cause the test to stop executing but still report as passed (rather than failed). xunit/xunit#3153

  • BUG: There was a bug in TestFinished.Attachments where the attachments were not correctly deserialized, so attachments were not visible to the test runners.

Assertion Library

  • We have added the ability to configure the maximum depth used by Assert.Equivalent when comparing two objects. By default, the maximum depth is 50 levels, after which the assertion will fail (to prevent infinite loops). You can override the default in the following ways (for example, to set the maximum depth to 123):

    • When using xunit.runner.json, add "assertEquivalentMaxDepth": 123 (JSON config docs)
    • When using RunSettings, add <AssertEquivalentMaxDepth>123</AssertEquivalentMaxDepth> (RunSettings docs)
    • When using xunit.v3.runner.console, add -assertEquivalentMaxDepth 123 (note that this will take effect when running a v3 test project linked against 1.1.0 or later)
    • When using dotnet run in xUnit.net native UX mode, add -assertEquivalentMaxDepth 123
    • When using dotnet run in Microsoft Testing Platform UX mode, add --assert-equivalent-max-depth 123
    • When using dotnet test in VSTS mode, add -- xUnit.AssertEquivalentMaxDepth=123
    • When using dotnet test in Microsoft Testing Platform mode, add -- --assert-equivalent-max-depth 123
    • To configure via environment variable, set XUNIT_ASSERT_EQUIVALENT_MAX_DEPTH=123

  • BUG: Fixed an issue where calling Assert.Equal with two ImmutableArray<T> instances would fail to properly compare the collections. xunit/xunit#3137

  • The assertion library source has been updated to remove support for Core Framework v2. We have removed the XUNIT_IMMUTABLE_COLLECTIONS, XUNIT_SKIP, and XUNIT_SPAN build flags, as these features are now permanently enabled. The minimum target frameworks have also been updated to .NET Framework 4.7.2 and .NET 6, as well as moving the minimum C# version up to 7.3. More information about source-based consumption (via xunit.v3.assert.source or Git submodule) is available in the updated README. For users who are still consuming the submodule for v2 support should stick to the v2 branch.

Argument Display (Core Framework & Assertion Library)

We have created overrides for the way some values are displayed in parameter lists in [Theory] display names as well as when printed in assertion failure messages.

  • You can configure the maximum length used when printing collections (enumerables), after which ellipses will be shown. By default, the maximum length is 5. You can override the default in the following ways (for example, to set the maximum length to 123):

    • When using xunit.runner.json, add "printMaxEnumerableLength": 123 (JSON config docs)
    • When using RunSettings, add <PrintMaxEnumerableLength>123</PrintMaxEnumerableLength> (RunSettings docs)
    • When using xunit.v3.runner.console, add -printMaxEnumerableLength 123 (note that this will take effect when running a v3 test project linked against 1.1.0 or later)
    • When using dotnet run in xUnit.net native UX mode, add -printMaxEnumerableLength 123
    • When using dotnet run in Microsoft Testing Platform UX mode, add --print-max-enumerable-length 123
    • When using dotnet test in VSTS mode, add -- xUnit.PrintMaxEnumerableLength=123
    • When using dotnet test in Microsoft Testing Platform mode, add -- --print-max-enumerable-length 123
    • To configure via environment variable, set XUNIT_PRINT_MAX_ENUMERABLE_LENGTH=123

    If you set the value to 0, collections are always printed in their entirety. xunit/xunit#2469

  • You can configure the maximum depth used when printing objects, after which ellipses will be shown. This controls the number of child objects that will be printed. By default, the maximum depth is 3. You can override the default in the following ways (for example, to set the maximum depth to 123):

    • When using xunit.runner.json, add "printMaxObjectDepth": 123 (JSON config docs)
    • When using RunSettings, add <PrintMaxObjectDepth>123</PrintMaxObjectDepth> (RunSettings docs)
    • When using xunit.v3.runner.console, add -printMaxObjectDepth 123 (note that this will take effect when running a v3 test project linked against 1.1.0 or later)
    • When using dotnet run in xUnit.net native UX mode, add -printMaxObjectDepth 123
    • When using dotnet run in Microsoft Testing Platform UX mode, add --print-max-object-depth 123
    • When using dotnet test in VSTS mode, add -- xUnit.PrintMaxObjectDepth=123
    • When using dotnet test in Microsoft Testing Platform mode, add -- --print-max-object-depth 123
    • To configure via environment variable, set XUNIT_PRINT_MAX_OBJECT_DEPTH=123

    If you set the value to 0, all child objects are always printed. Be careful when using 0, as printing objects with circular references will cause your test process to crash with an out of stack exception.

  • You can configure the maximum number of members to show when printing objects, after which ellipses will be shown. By default, the maximum member count is 5. You can override the default in the following ways (for example, to set the maximum member count to 123):

    • When using xunit.runner.json, add "printMaxObjectMemberCount": 123 (JSON config docs)
    • When using RunSettings, add <PrintMaxObjectMemberCount>123</PrintMaxObjectMemberCount> (RunSettings docs)
    • When using xunit.v3.runner.console, add -printMaxObjectMemberCount 123 (note that this will take effect when running a v3 test project linked against 1.1.0 or later)
    • When using dotnet run in xUnit.net native UX mode, add -printMaxObjectMemberCount 123
    • When using dotnet run in Microsoft Testing Platform UX mode, add --print-max-object-member-count 123
    • When using dotnet test in VSTS mode, add -- xUnit.PrintMaxObjectMemberCount=123
    • When using dotnet test in Microsoft Testing Platform mode, add -- --print-max-object-member-count 123
    • To configure via environment variable, set XUNIT_PRINT_MAX_OBJECT_MEMBER_COUNT=123

    If you set the value to 0, objects are always printed in their entirety.

  • You can configure the maximum length used when printing strings, after which ellipses will be shown. By default, the maximum length is 50. You can override the default in the following ways (for example, to set the maximum length to 123):

    • When using xunit.runner.json, add "printMaxStringLength": 123 (JSON config docs)
    • When using RunSettings, add <PrintMaxStringLength>123</PrintMaxStringLength> (RunSettings docs)
    • When using xunit.v3.runner.console, add -printMaxStringLength 123 (note that this will take effect when running a v3 test project linked against 1.1.0 or later)
    • When using dotnet run in xUnit.net native UX mode, add -printMaxStringLength 123
    • When using dotnet run in Microsoft Testing Platform UX mode, add --print-max-enumerable-length 123
    • When using dotnet test in VSTS mode, add -- xUnit.PrintMaxEnumerableLength=123
    • When using dotnet test in Microsoft Testing Platform mode, add -- --print-max-enumerable-length 123
    • To configure via environment variable, set XUNIT_PRINT_MAX_ENUMERABLE_LENGTH=123

    If you set the value to 0, strings are always printed in their entirety. xunit/xunit#1805

Runner Utility and Runners

  • BUG: Runners using xunit.v3.runner.utility were not correctly reading the default App.config file for v1/v2 .NET Framework projects. Third party runners will need to update to the newer version of xunit.v3.runner.utility to fix the issue. xunit/xunit#3130

NuGet Packages

  • We have updated the xunit.v3.core NuGet package to print an error message if you forget to add <OutputType>Exe</OutputType> to your project file. Previously we were trying to set it for you, but this causes build errors on .NET Framework, NuGet package restore and build are done inconsistently (the restore does not have <OutputType> set whereas the build does).

    Similarly, we require the app host when building for .NET, so we will print an error message if you have set <UseAppHost>false</UseAppHost>.

    If you are newly subject to this error because you've been linking against xunit.v3 or xunit.v3.core for non-test projects, please update to use xunit.v3.extensibility.core which is the package that's appropriate for non-test projects. microsoft/testfx#4469

Edit this page