Today, we're shipping xUnit.net 2.3; this includes RTM builds of the core framework and the Visual Studio runner. Ah, the sweet feeling of blue lights:
It's been nearly 8 months since the release of 2.2 RTM. That was strongly aligned with .NET Core 1.0, and in the intervening time, that team has now shipped a substantial 2.0 update. Similarly, xUnit.net 2.3 feels like it has a much improved experience for .NET Core users (both 1.x and 2.x).
One of the core reasons we've done xUnit.net has been to improve the day-to-day
unit testing experience for .NET developers. At a previous job, we had discussions
about adding Roslyn code analyzers to xUnit.net as a way to make our guidance
more concrete. These rules and fixes would represent our knowledge with issues
commonly faced by unit testers in general, and xUnit.net users in particular.
Marcin Dobosz, one of our co-workers at
the time, has stepped up and has done a tremendous job with the
xUnit.net Analyzers project.
Although this hasn't yet reached 1.0 status, we've already started including them
when you reference the
xunit meta-package; as a result, you will see
our guidance light up as warnings and errors in your code.
Visual Studio 2017 has seen some substantial improvements since its release 7 months ago, with some great things on the horizon with 15.4 and 15.5. We are currently working on updated templates for the next release of the .NET SDK and a future update to Visual Studio 2017 which will include 2.3 references.
As always, we'd like to thank all the users who contributed to the success of xUnit.net through usage, feedback, and code contributions. We had too many contributors this time around to thank individually, so know that every bug reported, every line of code PR'd, every conversation contributed to on Slack, were all appreciated!
xunitmeta-package now includes a reference to the
xunit.analyzerspackage automatically. We feel most users will benefit from these helpful rules and fixes. If you decide you would like to opt out, please remove your reference to
xunit, and instead add references to
[CollectionDefinition(DisableParallelization = true)]). Parallel-capable test collections will be run first (in parallel), followed by parallel-disabled test collections (run sequentially).
dotnet xunit. This gives a first class experience for running xUnit.net tests that mirrors the functionality available to desktop CLR users via
xunit.console.exe. We have updated Getting Started with .NET Core to show how to incorporate support for
xunit.runner.consoleNuGet package, and can be run via
dotnet C:\Path\to\xunit.console.dll C:\Path\to\TestLibrary.dll. There are additional properties via MSBuild that can be used to automatically locate the runner; see the xUnit.net Integration Project for examples of how to use this directly from your
System.Data.SqlClient) from .NET Core should now be able to properly use these packages (this fix affects all versions of .NET Core).
xunit.runner.console NuGet package has been changed; notably, the path
net452 executables has moved from
tools\net452\. You will need to update any paths which previously hard-coded
xunit.runner.msbuild NuGet package has been changed; notably, the names
of the MSBuild runner DLLs now include the target platform. This means if you had a
hard-coded path to
xunit.runner.msbuild.dll, this will need to be replaced
If you are using Visual Studio 2013, you must use NuGet 2.12 or
later to use xUnit.net 2.3, because support for
required. You will not be able to use xUnit.net 2.3 with Visual Studio 2012
(if Visual Studio 2012 support is important, please stick with xUnit.net 2.1,
the last version that officially supported 2012).
As a reminder: If you're extending xUnit.net and want to publish your extension
as a NuGet package, you should import
xunit.core. If you do this wrong, you might have problems generating
your NuGet package via
These release notes just include the highlights of what's new. You can review the individual release notes which contributed to 2.3: