build-and-test | SkillBundle

Only UnitTest projects need to be run locally; IntegrationTests require external dependencies.
See ../project-structure/SKILL.md for project structure details.

Build, Test, and Lint Commands

# From dotnet/ directory
dotnet restore --tl:off   # Restore dependencies for all projects
dotnet build --tl:off     # Build all projects
dotnet test               # Run all tests
dotnet

Use --tl:off when building to avoid flickering when running commands in the agent.

Speeding Up Builds and Testing

The full solution is large. Use these shortcuts:

Change type	What to do
Isolated/Internal logic	Build only the affected project and its `*.UnitTests` project. Fix issues, then build the full solution and run all unit tests.
Public API surface	Build the full solution and run all unit tests immediately.

Example: Building a single code project for all target frameworks

Example: Building a single code project for just .NET 10.

Example: Running tests for a single project using .NET 10.

Example: Running a single test in a specific project using .NET 10. Provide the full namespace, class name, and method name for the test you want to run:

Multi-target framework tip

Most projects target multiple .NET frameworks. If the affected code does not use #if directives for framework-specific logic, pass -f net10.0 to speed up building and testing.

Package Restore tip

dotnet build will try and restore packages for all projects on each build, which can be slow. Unless packages have been changed, or it's the first time building the solution, add --no-restore to the build command to skip this step and speed up builds.

Just remember to run dotnet restore after pulling changes, making changes to project references, or when building for the first time.

Testing on Linux tip

Unit tests target both .NET Framework as well as .NET Core. When running on Linux, only the .NET Core tests can be run, as .NET Framework is not supported on Linux.

To run only the .NET Core tests, use the -f net10.0 option with dotnet test.

Microsoft Testing Platform (MTP)

Tests use the Microsoft Testing Platform via xUnit v3. Key differences from the legacy VSTest runner:

dotnet test requires --project to specify a test project directly (positional arguments are no longer supported).
Test output uses the MTP format (e.g., [✓112/x0/↓0] progress and Test run summary: Passed!).
TRX reports use --report-xunit-trx instead of --logger trx.
Code coverage uses Microsoft.Testing.Extensions.CodeCoverage with --coverage --coverage-output-format cobertura.
Running a test project directly is supported via dotnet run --project <test-project>. This bypasses the dotnet test infrastructure and runs the test executable directly with the MTP command line.
Running tests across the solution with a filter may cause some projects to match zero tests, which MTP treats as a failure (exit code 8). Use --ignore-exit-code 8 to suppress this:

Running tests with --solution for a specific TFM requires all projects in the solution to support that TFM. Not all projects target every framework (e.g., some are net10.0-only). Use ./dotnet/eng/scripts/New-FilteredSolution.ps1 to generate a filtered solution:

Only UnitTest projects need to be run locally; IntegrationTests require external dependencies.
See ../project-structure/SKILL.md for project structure details.

Build, Test, and Lint Commands

# From dotnet/ directory
dotnet restore --tl:off   # Restore dependencies for all projects
dotnet build --tl:off     # Build all projects
dotnet test               # Run all tests
dotnet

Use --tl:off when building to avoid flickering when running commands in the agent.

Speeding Up Builds and Testing

The full solution is large. Use these shortcuts:

Change type	What to do
Isolated/Internal logic	Build only the affected project and its `*.UnitTests` project. Fix issues, then build the full solution and run all unit tests.
Public API surface	Build the full solution and run all unit tests immediately.

Example: Building a single code project for all target frameworks

Example: Building a single code project for just .NET 10.

Example: Running tests for a single project using .NET 10.

Example: Running a single test in a specific project using .NET 10. Provide the full namespace, class name, and method name for the test you want to run:

Multi-target framework tip

Most projects target multiple .NET frameworks. If the affected code does not use #if directives for framework-specific logic, pass -f net10.0 to speed up building and testing.

Package Restore tip

Just remember to run dotnet restore after pulling changes, making changes to project references, or when building for the first time.

Testing on Linux tip

Unit tests target both .NET Framework as well as .NET Core. When running on Linux, only the .NET Core tests can be run, as .NET Framework is not supported on Linux.

To run only the .NET Core tests, use the -f net10.0 option with dotnet test.

Microsoft Testing Platform (MTP)

Tests use the Microsoft Testing Platform via xUnit v3. Key differences from the legacy VSTest runner:

dotnet test requires --project to specify a test project directly (positional arguments are no longer supported).
Test output uses the MTP format (e.g., [✓112/x0/↓0] progress and Test run summary: Passed!).
TRX reports use --report-xunit-trx instead of --logger trx.
Code coverage uses Microsoft.Testing.Extensions.CodeCoverage with --coverage --coverage-output-format cobertura.
Running a test project directly is supported via dotnet run --project <test-project>. This bypasses the dotnet test infrastructure and runs the test executable directly with the MTP command line.
Running tests across the solution with a filter may cause some projects to match zero tests, which MTP treats as a failure (exit code 8). Use --ignore-exit-code 8 to suppress this:

Running tests with --solution for a specific TFM requires all projects in the solution to support that TFM. Not all projects target every framework (e.g., some are net10.0-only). Use ./dotnet/eng/scripts/New-FilteredSolution.ps1 to generate a filtered solution: