Analyzers 1.11.0 - Xunit

Today, we're shipping three new releases:

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

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 comprehensive list of changes from 1.10.0 to 1.11.0.

We have removed support for Roslyn 4.2, as Visual Studio 2022 17.2 is no longer supported by Microsoft. If you are still running this version Visual Studio, the analyzers may not work for you. We are still supporting Visual Studio 2019 16.11, as well as Visual Studio 2022 17.4 (or later).

We have fixed an issue with false positives from xUnit1039 when using anonymous tuples where the types matched but the names did not (for example, (string foo, string bar) is equivalent to (string, string) as well as (string baz, string biff), since the names are used as compile-time shortcuts and don't impact the underlying tuple type). xunit/xunit#2873{ .issue-link }
We have added support for generic fixture collection to v3 Core Framework 0.1.1-pre.366, and have updated xUnit1041 to ensure that it recognizes the new source for fixture data. xunit/xunit#2557{ .issue-link }

We have added support for IAsyncEnumerable<T> in several assertions in v2 Core Framework 2.7.0. We've updated several assertion analyzers that cover usage of IEnumerable<T> to ensure they also cover async enumerables.
We have extended xUnit2011 to include Assert.CollectionAsync.
We have fixed an issue with xUnit2014 where the fixer would apply the async attribute at the wrong level when the problematic code lived inside a lambda or a private function of the test method. The fixer will now apply async to the right function, and it will climb through all the parent functions/lambdas adding async to them as well as needed. However, it will only add await to the original problematic code. The resulting fixed code may need additional work to ensure that it is properly awaiting any of the functions/lambdas in use, which the compiler should be able to highlight with CS1998, CS4014, and CS0029 if there are any resulting type incompatibilities. <em>If you are suppressing any of these errors or warnings, you may end up with code that is broken at runtime.</em> xunit/xunit#{ .issue-link }