Build, test and modernization

Build

build_project  projectName=MyApp.Api

Runs dotnet build and returns structured errors and warnings — id, severity, file, line, message. It also runs the configured analyzers by default, and compiles without copying output so a running app does not lock the DLL. Around it: get_diagnostics for the compiler's current view without a build, analyze_binlog for the real per-project and per-target durations of a build, and project_properties for the evaluated value of an MSBuild property — what Directory.Build.props, imports and conditions contribute, which is the value the compiler actually sees.

Run

run_project  projectName=MyApp.Api timeoutSeconds=15

Launches dotnet run, captures output and returns when the timeout expires. For a web app the startup output includes the listening URL — exactly what you need before calling http_invoke against it. The arguments an app needs are written once, not on every call: run_config saves named launch shapes (project, arguments, configuration, environment) in a file that can be committed, and run_project configName=… applies them. launch_settings edits the profiles the IDE uses, without reformatting the rest of the document.

Test

run_tests
get_test_coverage_map  minCoverage=60

run_tests parses every TRX file produced and returns the totals, a per-project breakdown and each failure with its message and stack trace. get_test_coverage_map runs the suite with coverage and returns per-class and per-method line coverage. run_affected_tests narrows a run to the tests that reach the changed code, and verify_change runs the suite on the working tree and on a git revision, then diffs the outcome test by test — a verdict on whether behaviour was preserved, not just a pass count.

Benchmarks

run_benchmarks builds and runs an existing BenchmarkDotNet project; quick_benchmark benchmarks an ad-hoc snippet without writing a [Benchmark] class — it generates a temporary project, optionally references your solution's project and returns time and allocations.

NuGet packages

Goal	Tool
What is installed, per target framework, with version conflicts	list_nuget_packages
Available upgrades	check_nuget_updates
Known vulnerabilities	check_nuget_vulnerabilities
Fix vulnerable top-level packages	fix_nuget_vulnerabilities
Read a package's public API, or decompile one type	inspect_package, decompile_package_type
Add, remove, update, unify one version across projects	add_nuget_package, update_nuget_package, unify_nuget_version

package_facts is the NuGet graph the build already resolved — from obj/project.assets.json, no restore, no network — with the versions the compiler actually sees.

Publish

dotnet_publish runs the publish — runtime identifier, self-contained, single-file, output folder — and returns it as data. publish_profile authors the *.pubxml the same publish reads, so a filesystem target is defined without an IDE; nuget_pack and nuget_push cover the package half.

Modernization

Three tools, all preview-first and all with a build gate that rolls back on failure.

• aspire — reports the SDK band and what is installed, installs the templates, and scaffolds the AppHost and ServiceDefaults with the wiring written and verified by a build; if the wiring does not compile, the edits are reverted.
• update_framework — moves the projects to a newer target framework, keeping platform suffixes and leaving netstandard/net4x alone. The preview returns the plan; the write builds the whole solution and, on failure, restores every edited file byte for byte.
• update_solution — the framework bump plus every outdated top-level package, in the right order (Central Package Management included). Deliberately does not run tests: a slow suite should not turn an upgrade into a timeout — run them after.

A typical loop

build_project     → structured errors
apply_code_fix    → fix one finding
build_project     → verify
run_tests         → verify behaviour
inspect_code      → catch what the compiler does not
quick_benchmark   → check a hot path did not regress

For a mechanical fan-out — the same simplify_code over ten documents, then a build — run_plan executes the whole graph in one round trip. See the Workflow guide.