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
than the placeholder
Assert.NotNull<T>() overload designed for nullable value types.
Assert.Equal with dictionaries where the
was a collection class (like an array or
HashSet values, where the
internal comparer (passed during construction of the
HashSet) and/or the external comparer (passed
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
and an implementation of
GetHashCode that was throwing; it now correctly delegates to the instance
IEqualityComparer<T> that it is wrapping.
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
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
Assert.Equal, which still consults several equality-testing interfaces.