» Release Notes
» Release Notes
This is co-released with
xunit.analyzers version 1.3.0-pre.6 and
xunit.runner.visualstudio version 2.5.1-pre.4.
The 2.5.1 release will be primarily focused on fixing issues introduced with the newly overhauled assertion library, as well as integrating in any other bug fixes along the way that we've discovered.
Users have reported sporadic problems restoring the version 2.5.0 NuGet packages. This is a result of .NET Foundation's
code signing system changing the default time stamp server from DigiCert to Microsoft, which is not supported on .NET SDK
6.0.3xx (which is associated with Visual Studio 2022 LTS release 17.2). Users who were trying to stick with purely LTS
builds of tools experienced NU3003
("The package signature is invalid or cannot be verified on this platform."). We have manually reverted back to the
DigiCert time stamp service, which will allow users relying on LTS tooling to be able to restore our packages again.
At this point in time, it is unclear whether this will be fixable for .NET SDK 6.0.3xx or not (and whether the proposed
fix in this issue will actually work on all OSes or just
Windows). Regardless of whether this change is applied or not, it is our intention to permanently stick with the DigiCert
time stamp service because it provides maximum compatibility with currently shipping versions of the SDK.
BitArray class has been marked as "safe to re-enumerate", so when it is printed in error messages
and/or theory data, it will show the bit values (as an array of True and False) rather
than the placeholder [···].
Assert.NotNull<T>() overload designed for nullable value types.
xunit/xunit#2750
Assert.Equal with dictionaries where the TValue
was a collection class (like an array or List<T>).
xunit/xunit#2755
Assert.Equal with HashSet values, where the
internal comparer (passed during construction of the HashSet) and/or the external comparer (passed
to Assert.Equal) was not being used, causing false positives or negatives. Part of the implementation
of this fix also resolves a potential issue (never reported) with internal type AssertEqualityComparerAdapter
and an implementation of GetHashCode that was throwing; it now correctly delegates to the instance
of IEqualityComparer<T> that it is wrapping.
xunit/xunit#2743
Assert.Equivalent with some tuple values where the comparison
was failing, even when the values should've been equivalent. This involved rewriting some sketchy logic related to
IComparable which had previously been added just to support DateTime and DateTimeOffset;
now, instead, we explicitly handle those two types and never try to use IComparable. This is more in line
with the originally intended purpose of Assert.Equivalent, but it may now surface as unexpected false
negatives if any developers were relying on us calling their IComparable implementation. The new logic is
the correct intention, and developers should not assume that we will use IComparable (or any other
similar interface) for Assert.Equivalent. Note that this does not affect our implementation
of Assert.Equal, which still consults several equality-testing interfaces.
xunit/xunit#2758