docs: make examples work on Linux and macOS

benchmarks/TUnit.Performance.Tests/README.md

@@ -37,25 +37,29 @@ dotnet run -c Release
 
 ### Native AOT Comparison
 
+Native AOT needs a platform toolchain: the Visual Studio "Desktop development with C++" workload on Windows, the Xcode Command Line Tools on macOS, and `clang` plus the zlib development package on Linux. See the [.NET Native AOT prerequisites](https://learn.microsoft.com/dotnet/core/deploying/native-aot/#prerequisites).
+
 ```bash
-# Build for AOT
-dotnet publish -c Release -r win-x64 --self-contained -p:PublishAot=true
+# Build for AOT (native AOT cannot cross-compile across operating systems, so target the current machine)
+dotnet publish -c Release --use-current-runtime --self-contained -p:PublishAot=true -o publish
 
 # Run the published executable
-./bin/Release/net8.0/win-x64/publish/TUnit.Performance.Tests.exe
+./publish/TUnit.Performance.Tests
+# On Windows:
+./publish/TUnit.Performance.Tests.exe
 ```
 
 ### Run Specific Benchmarks
 
 ```bash
 # Run only discovery benchmarks
-dotnet run -c Release -- --filter *Discovery*
+dotnet run -c Release -- --filter '*Discovery*'
 
 # Run only execution benchmarks
-dotnet run -c Release -- --filter *Execution*
+dotnet run -c Release -- --filter '*Execution*'
 
 # Run only data source benchmarks
-dotnet run -c Release -- --filter *DataSource*
+dotnet run -c Release -- --filter '*DataSource*'
 ```
 
 ## Expected Results

docs/docs/comparison/framework-differences.md

@@ -65,7 +65,7 @@ TUnit creates a new instance for every test, with no way to opt out. If you need
 
 Consider a multi-tenanted test suite where tests repeat with different tenants injected via `[TestFixtureSource]`. A natural next step is filtering by tenant. In NUnit, you might try using `IApplyToTest` to set a property based on the constructor argument, but it doesn't work — tests are enumerated at startup before the fixture source provides its values.
 
-Because TUnit discovers tests via source generation, constructor arguments are available upfront. You can set properties with `ITestDiscoveryEvent` and filter with `--treenode-filter /*/*/*/*[Tenant=MyTenant]`.
+Because TUnit discovers tests via source generation, constructor arguments are available upfront. You can set properties with `ITestDiscoveryEvent` and filter with `--treenode-filter "/*/*/*/*[Tenant=MyTenant]"`.
 
 ### Attribute scope
 

docs/docs/examples/filebased-csharp.md

@@ -19,7 +19,7 @@ To use TUnit with a file-based C# application, you can follow these steps:
         #:package TUnit@1.6.0
         ```
 
-    -   You can also use msbuild props files to include TUnit. By creating a `Directory.build.props` file in the same directory as the csharp file.
+    -   You can also use msbuild props files to include TUnit. By creating a `Directory.Build.props` file in the same directory as the csharp file.
 
         ```xml
         <Project>
@@ -72,7 +72,7 @@ dotnet project convert Program.cs
 
 Single file csharp applications can also be used with msbuild props files. You can create a `*.props` file and the dotnet sdk will automatically include it when running the file-based application.
 
-1. Create a file named `Directory.build.props` with the following content:
+1. Create a file named `Directory.Build.props` with the following content:
 
     ```xml
     <Project>
@@ -112,4 +112,4 @@ Single file csharp applications can also be used with msbuild props files. You c
     dotnet run file.cs
     ```
 
-This will automatically include the `Directory.build.props` file as long as it is in the same directory as the csharp file, and you will be able to run your tests with TUnit.
+This will automatically include the `Directory.Build.props` file as long as it is in the same directory as the csharp file, and you will be able to run your tests with TUnit.

docs/docs/getting-started/running-your-tests.md

@@ -12,8 +12,8 @@ Coverage and TRX reporting are built in. See [Extensions](../extending/built-in-
 
 For a simple execution of a project, `dotnet run` is the preferred method, allowing easier passing in of command line flags.
 
-```powershell
-cd 'C:/Your/Test/Directory'
+```sh
+cd path/to/YourTestProject
 dotnet run -c Release
 # or with flags
 dotnet run -c Release --report-trx --coverage
@@ -23,8 +23,8 @@ dotnet run -c Release --report-trx --coverage
 
 `dotnet test` requires any command line flags to be specified as application arguments, meaning after a `--` - Otherwise you'll get an error about unknown switches.
 
-```powershell
-cd 'C:/Your/Test/Directory'
+```sh
+cd path/to/YourTestProject
 dotnet test -c Release
 # or with flags
 dotnet test -c Release -- --report-trx --coverage
@@ -34,17 +34,17 @@ dotnet test -c Release -- --report-trx --coverage
 
 If your test project has already been built, you can use `dotnet exec` or just `dotnet` with the `.dll` path
 
-```powershell
-cd 'C:/Your/Test/Directory/bin/Release/net8.0'
+```sh
+cd path/to/YourTestProject/bin/Release/net8.0
 dotnet exec YourTestProject.dll
 # or with flags
 dotnet exec YourTestProject.dll --report-trx --coverage
 ```
 
 or
 
-```powershell
-cd 'C:/Your/Test/Directory/bin/Release/net8.0'
+```sh
+cd path/to/YourTestProject/bin/Release/net8.0
 dotnet YourTestProject.dll
 # or with flags
 dotnet YourTestProject.dll --report-trx --coverage
@@ -57,11 +57,20 @@ On Windows this will be a `.exe` and on Linux/macOS there will be no extension.
 
 This can be invoked directly and passed any flags.
 
-```powershell
-cd 'C:/Your/Test/Directory/bin/Release/net8.0/win-x64/publish'
-./YourTestProject.exe
+The publish folder sits under the runtime identifier you published for, such as `win-x64`, `linux-x64` or `osx-arm64`. Replace `linux-x64` below with yours.
+
+```sh
+cd path/to/YourTestProject/bin/Release/net8.0/linux-x64/publish
+./YourTestProject
 # or with flags
-./YourTestProject.exe --report-trx --coverage
+./YourTestProject --report-trx --coverage
+```
+
+On Windows, from the `win-x64` publish folder:
+
+```powershell
+cd path/to/YourTestProject/bin/Release/net8.0/win-x64/publish
+.\YourTestProject.exe --report-trx --coverage
 ```
 
 ## IDE Support

docs/docs/writing-tests/test-context.md

@@ -100,7 +100,7 @@ See the [Test Parameters](../execution/parameters.md) guide for full details.
 
 Custom properties can be added to a test using the `[Property]` attribute. Properties are key-value pairs of strings that serve multiple purposes:
 
-- **Test filtering**: Filter tests at the command line with `dotnet run --treenode-filter /*/*/*/*[PropertyName=PropertyValue]`
+- **Test filtering**: Filter tests at the command line with `dotnet run --treenode-filter "/*/*/*/*[PropertyName=PropertyValue]"`
 - **Runtime logic**: Access properties in setup/cleanup hooks via `TestContext` to conditionally execute logic
 - **Inheritance**: Apply `[Property]` on a base class and all sub-class tests inherit it