diff --git a/BUILDING.md b/BUILDING.md index 631b7cfe..7a2c3692 100644 --- a/BUILDING.md +++ b/BUILDING.md @@ -1,7 +1,6 @@ # Building xUnit.net Analyzers -The primary build system for xUnit.net Analyzers is done via command line, and officially supports Linux and Windows. Users -running macOS can generally follow the Linux instructions (while installing the macOS equivalents of the dependencies). +The primary build system for xUnit.net Analyzers is done via command line, and officially supports Linux and Windows. Users running macOS can generally follow the Linux instructions (while installing the macOS equivalents of the dependencies). # Pre-Requisites @@ -17,25 +16,24 @@ Linux users will additionally need: * [Mono](https://www.mono-project.com/download/stable/) 6.12+ * [bash](https://www.gnu.org/software/bash/) -Note: Linux users cannot run the .NET Framework tests, as they are incompatible. For this reason, we recommend that -users either work primarily in Windows, or verify their tests work as expected in a Windows VM, before submitting PRs. +Note: Linux users cannot run the .NET Framework tests, as they are incompatible. For this reason, we recommend that users either work primarily in Windows, or verify their tests work as expected in a Windows VM, before submitting PRs. ## Windows Pre-Requisites Windows users will additionally need: * .NET Framework 4.7.2 or later (part of the Windows OS) -* PowerShell (or [PowerShell Core](https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-core-on-windows?view=powershell-6)) +* [PowerShell 7+](https://learn.microsoft.com/powershell/scripting/install/installing-powershell-on-windows) -Ensure that you have configured PowerShell to be able to run local unsigned scripts (either by running -`Set-ExecutionPolicy RemoteSigned` from within PowerShell, or by launching PowerShell with the -`-ExecutionPolicy RemoteSigned` command line switch). +Ensure that you have configured PowerShell to be able to run local unsigned scripts (either by running `Set-ExecutionPolicy RemoteSigned` from within PowerShell, or by launching PowerShell with the `-ExecutionPolicy RemoteSigned` command line switch). + +_Note that the built-in version of PowerShell may work, but is unsupported by us. If you have PowerShell-related issues, please make sure you have installed PowerShell 7+ and the command prompt you opened is for PowerShell 7+, and not the built-in version of PowerShell._ # Command-Line Build 1. **Linux users:** Open a terminal to your favorite shell. - **Windows users:** Open PowerShell (or PowerShell Core). + **Windows users:** Open PowerShell 7+. 1. From the root folder of the source repo, this command will build the code & run all tests: @@ -50,9 +48,6 @@ Ensure that you have configured PowerShell to be able to run local unsigned scri * `Restore`: Perform package restore * `Build`: Build the source * `Test`: Run all unit tests - * `TestCore`: Run all unit tests (.NET Core) - * `TestFx`: Run all unit tests (.NET Framework) - * `Packages`: Create NuGet packages You can get a list of options: @@ -60,28 +55,26 @@ Ensure that you have configured PowerShell to be able to run local unsigned scri # Editing source -In order to support multiple versions of Roslyn (the compiler API), we have created separated projects for backward -compatibility. The primary projects targeting the latest supported version of Roslyn are: +The primary projects for editing are: * `xunit.analyzers` (for code analysis) * `xunit.analyzers.fixes` (for automated fixes for issues raised in code analysis) * `xunit.analyzers.tests` (for unit tests of both above projects) -When working on new or existing analyzers, fixes, and tests, please work in these projects. They reside in the folder -with the source code for the appropriate project. +These are targeting our lowest common denominator for Roslyn (current version 3.11, the version that's supported in Visual Studio 2019 16.11). + +There are also three projects which build against the latest version of Roslyn: + +* `xunit.analyzers.latest` +* `xunit.analyzers.latest.fixes` +* `xunit.analyzers.latest.tests` + +When running a command line build, we run a matrix of 4 test projects: Roslyn 3.11 vs. latest, and .NET Framework vs. .NET. It's important that you run `./build` (or `./build test`) from Windows before submitting PRs, because some bugs are often found only in one of the four combinations (and Mono cannot run the .NET Framework tests). -You will also see several backward compatibility projects, with `roslyn` in their name, to indicate which older -version of the Roslyn API they target (for example, `xunit.analyzers.roslyn311` targets Roslyn 3.11, which -[supports Visual Studio 2019 16.11](https://learn.microsoft.com/en-us/visualstudio/extensibility/roslyn-version-support)). -These projects automatically pick up source files from the main projects. It is expected that the single set of -source code applies to all compiled projects. +You will also occasionally see tests which only run in specific environments. Common `#if` statements you may see (or may need to use) include: -If code needs to be conditioned based on the version of Roslyn, there are two categories of preprocessor definitions -that you can use to gate your code and/or tests. For exact versions, you can reference a specific version like -`ROSLYN_3_11`, and for minimum versions, you can reference a symbol like `ROSLYN_3_11_OR_GREATER`. Note that we only -provide definitions for the exact versions we support. For a list of those symbols and supported versions, -please see [`Directory.Build.props`](https://github.com/xunit/xunit.analyzers/blob/main/src/Directory.Build.props). +* `#if NETFRAMEWORK` (only runs for .NET Framework) +* `#if NETCOREAPP` (only runs for .NET) +* `#if ROSLYN_LATEST` (only runs with latest Roslyn, which includes getting analysis test support to C# language > version 9) -While iterating in the IDE, it will be common to work just inside the primary projects, including just running the tests -from the primary test project. Before submitting a PR, please run `./build test` (from Windows) so that you can ensure -that all code & tests work with all supported versions of Roslyn. +In production code, we try to minimize these when possible, and prefer to fall back to use dynamic runtime environment detection when we can (as we'd like to light up features in newer versions of Roslyn when available). While this isn't always possible, it is generally a goal we try to achieve. In test code, we tend to use these to more frequently to ensure we have complete coverage of features that should be available dynamically (whether they are lit up based on `#if` or by runtime environment detection).