If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/dotnet/msbuild shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit today
• 21+ active contributors
• Distributed ownership (top contributor 33% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live dotnet/msbuild repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/dotnet/msbuild.

What it runs against: a local clone of dotnet/msbuild — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in dotnet/msbuild | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of dotnet/msbuild. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/dotnet/msbuild.git
#   cd msbuild
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of dotnet/msbuild and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "dotnet/msbuild(\\.git)?\\b" \\
  && ok "origin remote is dotnet/msbuild" \\
  || miss "origin remote is not dotnet/msbuild (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f ".github/copilot-instructions.md" \\
  && ok ".github/copilot-instructions.md" \\
  || miss "missing critical file: .github/copilot-instructions.md"
test -f ".github/CODEOWNERS" \\
  && ok ".github/CODEOWNERS" \\
  || miss "missing critical file: .github/CODEOWNERS"
test -f ".vsts-dotnet-ci.yml" \\
  && ok ".vsts-dotnet-ci.yml" \\
  || miss "missing critical file: .vsts-dotnet-ci.yml"
test -f ".vsts-dotnet.yml" \\
  && ok ".vsts-dotnet.yml" \\
  || miss "missing critical file: .vsts-dotnet.yml"
test -f ".editorconfig" \\
  && ok ".editorconfig" \\
  || miss "missing critical file: .editorconfig"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/dotnet/msbuild"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

MSBuild is the build engine and platform that powers Visual Studio and .NET builds, executing XML-based project files (.csproj, .vbproj, etc.) to compile, package, and orchestrate software builds. It provides a declarative task-based system for transforming source code into deployable artifacts, handling everything from C# compilation to NuGet packaging to custom build logic, and runs on both Windows (.NET Framework 4.7.2) and Unix (.NET Core). Monorepo structure: src/ contains the core engine (property evaluation, task execution), src/Tasks/ has ~100+ built-in tasks (Csc, Vbc, Exec, Copy, etc.), src/Framework/ provides the extensibility APIs, and src/Logging/ handles output. Entry points are src/MSBuild/MSBuild.cs (CLI) and src/BuildEngine/ (in-process engine). Tests are in src/UnitTests/ with task-specific and integration suites.

Build engineers, .NET developers building libraries and applications, Visual Studio contributors, and DevOps teams who need to automate builds outside the IDE. They use MSBuild both through Visual Studio's UI and directly via msbuild.exe for CI/CD pipelines and command-line build orchestration.

MSBuild is production-ready and actively maintained as a core Microsoft component. The repo shows 27M+ lines of C# code, extensive CI integration (Azure Pipelines and DevDiv internal builds), comprehensive GitHub issue templates for bug reports and features, and regular commits. This is enterprise-grade infrastructure used by millions of .NET developers daily.

Low risk for stability but high risk for breaking changes due to MSBuild's central role in the ecosystem—any change to XML schema, task APIs, or property evaluation affects downstream projects. The repository shows careful change management via .github/skills/changewaves/ and .config/1espt/PipelineAutobaseliningConfig.yml, indicating awareness of breaking-change risk. Single large monorepo means coordinating changes across engine, tasks, CLI, and logging is complex.

Based on file structure, active work areas include: BuildChecks framework (.github/instructions/buildcheck.instructions.md), logging improvements (src/Logging/), backend execution enhancements (.github/instructions/backend-execution.instructions.md), globbing patterns (.github/instructions/globbing.instructions.md), and changewaves management for coordinated API changes. Azure DevOps security scanning is enabled (.config/guardian/, .config/1espt/).

1. git clone https://github.com/dotnet/msbuild
2. Enable long paths on Windows: via registry
3. Open Developer Command Prompt for VS 2022
4. ./build.cmd (Windows) or follow documentation/wiki/Building-Testing-and-Debugging-on-.Net-Core-MSBuild.md (Linux/Mac)
5. Built binary: artifacts/bin/bootstrap/net472/MSBuild/Current/Bin/MSBuild.exe

Daily commands: This is a build tool, not a runnable app. To test locally: ./build.cmd compiles MSBuild itself, then invoke built binary: artifacts/bin/bootstrap/net472/MSBuild/Current/Bin/MSBuild.exe MyProject.csproj /p:Configuration=Release or use in Visual Studio by opening MSBuild.slnx or MSBuild.Dev.slnf.

• .github/copilot-instructions.md — Central guidance document for AI-assisted development in MSBuild; every contributor should understand the project's documentation standards and conventions
• .github/CODEOWNERS — Defines ownership and review requirements for each component; critical for understanding who owns what and PR review expectations
• .vsts-dotnet-ci.yml — Primary CI/CD pipeline configuration for MSBuild; essential for understanding build, test, and validation stages
• .vsts-dotnet.yml — Secondary CI/CD configuration managing official builds and releases; critical for release process understanding
• .editorconfig — Defines code style, formatting, and language-level conventions across the entire codebase
• .github/instructions/tasks.instructions.md — Detailed guidance on MSBuild task development and implementation patterns; essential for contributors adding new tasks
• .github/skills/reviewing-msbuild-code/SKILL.md — Code review patterns and best practices specific to MSBuild; fundamental for contribution quality standards

• Build Engine Core (C#, expression evaluator, task runners) — Orchestrates project file parsing, property/item evaluation, and target execution graph; manages task scheduling and parallelization
  • Failure mode: Malformed project files, circular dependencies, or deadlocks in parallel execution halt the build; diagnostic output to console and binary log
• Task Framework — Provides abstract base classes for task implementation; handles marshaling, lifecycle, and logging integration

Add a New MSBuild Task

1. Review task implementation patterns and conventions (.github/instructions/tasks.instructions.md)
2. Examine the code review checklist to ensure multithreading compliance (.github/skills/reviewing-msbuild-code/SKILL.md)
3. Verify logging follows the established diagnostic conventions (.github/instructions/logging.instructions.md)
4. Add unit tests following the framework-specific patterns (.github/instructions/tests.instructions.md)

Implement a Build Check Feature

1. Review build check design and requirements (.github/instructions/buildcheck.instructions.md)
2. Follow the code review patterns to ensure quality (.github/skills/reviewing-msbuild-code/SKILL.md)
3. Configure logging for diagnostics and troubleshooting (.github/instructions/logging.instructions.md)
4. Ensure evaluation logic handles edge cases (.github/instructions/evaluation.instructions.md)

Optimize MSBuild Performance

1. Review performance optimization principles and patterns (.github/skills/optimizing-msbuild-performance/SKILL.md)
2. Apply code review best practices during implementation (.github/skills/reviewing-msbuild-code/SKILL.md)
3. Profile and measure improvements using MSBuild diagnostics (.github/instructions/logging.instructions.md)
4. Ensure backward compatibility and binary log stability (.github/skills/maintaining-binary-log-compatibility/SKILL.md)

Integrate with Visual Studio

1. Review integration patterns and SDK coordination (.github/skills/integrating-sdk-and-msbuild/SKILL.md)
2. Ensure changes support deployment to Visual Studio (.github/skills/deploy-msbuild-to-vs/SKILL.md)
3. Verify version coordination with .NET SDK (.github/instructions/framework.instructions.md)
4. Follow review checklist for MSBuild code (.github/skills/reviewing-msbuild-code/SKILL.md)

• C# / .NET — MSBuild is the platform for .NET and Visual Studio; native language ensures deep OS integration and performance
• **XML Project Files (.csproj, .vbproj) — MSBuild's core schema for build orchestration; declarative format enables ecosystem tooling and IDE integration
• Azure Pipelines / GitHub Actions — Industry-standard CI/CD for official releases and community validation; multi-platform testing required for .NET SDK
• Binary Logging (BinLog) — Performance-critical for large builds; enables offline analysis without source code re-evaluation
• 1ESPowerTools & Guardian — Enterprise security and compliance scanning; required for official Microsoft releases

• Dual CI pipelines (.vsts-dotnet.yml internal, .vsts-dotnet-ci.yml public)

  • Why: Internal pipelines enable real-time releases to Visual Studio; public pipelines maintain community trust and transparency
  • Consequence: Configuration duplication and potential divergence; requires careful synchronization during changes

• Skill-based documentation over monolithic guide

  • Why: Reduces cognitive load for new contributors; localizes knowledge by feature area
  • Consequence: Distributed information requires explicit navigation; risk of inconsistent guidance if skills not updated together

• Binary log compatibility maintained across versions

  • Why: Enables offline debugging and historical analysis of builds from older MSBuild versions
  • Consequence: Strict schema constraints limit evolution of logging format; breaking changes require major version bumps

• Does not provide its own package manager—relies on .NET NuGet and Visual Studio Package Management

1. Long path limitation on Windows: Must enable via registry—paths >260 chars fail silently without this (mentioned in README).
2. Default task timeout: Tasks can hang; set MSBUILD_PROCESS_BUILDER_TIMEOUT_MILLISECONDS env var if customizing task execution.
3. Property circular references: $(Foo) inside Foo definition causes evaluation loop—no loop detection, infinite recursion.
4. Target graph assumptions: Adding cycles in target DependsOnTargets will silently break builds; use ProjectGraph validation.
5. Localization builds: Must pass /p:LocalizedBuild=true to include RESX translations—omitting it silently drops non-English resources.
6. BinaryLogger file handle: .binlog files are memory-mapped; can't delete on Windows until build completes.

• Property Evaluation and Substitution — MSBuild projects are declarative XML; understanding how $(PropertyName) is resolved at parse time vs. task execution time is critical to debugging build failures
• Directed Acyclic Graph (DAG) of Targets — The build process orders targets based on DependsOnTargets; cycles cause silent failures, and understanding topological sort is essential for optimizing build speed
• Task Factory and AppDomain Isolation — MSBuild can load tasks from arbitrary assemblies; TaskFactory handles AppDomain creation for isolation—understanding this prevents DLL load conflicts and assembly version mismatches
• Item Metadata and Batching — Tasks iterate over collections of items (e.g., source files) with optional metadata (e.g., compiler flags per file); batching logic in TaskExecutionHost enables cross-cutting transformations
• Binary Logging (BinLog Format) — MSBuild's structured binary log format enables offline analysis without re-running builds; understanding serialization is key to tooling integration
• Condition Evaluation and Expression Trees — XML Condition attributes are evaluated as boolean expressions (e.g., '$(OS)'=='Windows_NT'); the parser in Evaluator.cs is non-standard and has edge cases (e.g., string coercion rules)
• Project-to-Project References and Graph Building — Multi-targeting and cross-project dependencies are resolved via ProjectGraph—understanding transitivity and property flow between projects is critical for complex solutions

• dotnet/roslyn — C# and VB.NET compiler APIs that MSBuild invokes via Csc.cs and Vbc.cs tasks
• dotnet/sdk — .NET SDK provides the default MSBuild targets and props files that wrap MSBuild for .NET projects
• dotnet/project-system — Visual Studio project system layer that calls MSBuild and interprets results in the IDE
• microsoft/msbuild-structured-log-viewer — Standalone tool for analyzing MSBuild binary logs (.binlog files) produced by BinaryLogger
• dotnet/runtime — Consumer of MSBuild for building .NET runtime itself; tests build integration across platforms

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for MSBuild task execution in multithreaded scenarios

The repo has a skill file at .github/skills/multithreaded-task-migration/SKILL.md indicating active work on multithreading. However, there's no dedicated test suite visible for concurrent task execution edge cases. New contributors could add tests covering race conditions, deadlock scenarios, and thread-safe property access in task runners, which would directly support the multithreading migration initiative.

• [ ] Review .github/skills/multithreaded-task-migration/SKILL.md to understand current migration scope
• [ ] Identify core task execution files in src/Tasks and src/BackEnd directories
• [ ] Create new test file (e.g., src/Tests/Tasks.ConcurrencyTests.cs) with scenarios for parallel task execution
• [ ] Add tests for thread-safe logging in concurrent contexts (referenced in .github/instructions/logging.instructions.md)
• [ ] Ensure tests cover both in-proc and out-of-proc task execution

Implement BuildCheck diagnostic tests and documentation for all rule categories

The repo has .github/instructions/buildcheck.instructions.md and .github/ISSUE_TEMPLATE/07_buildchecksuggestion.yml, indicating BuildCheck is an active feature. However, there's no visible comprehensive test suite for diagnostic rule enforcement. Contributors could add exhaustive unit tests and integration tests for each BuildCheck rule category with corresponding documentation examples.

• [ ] Review .github/instructions/buildcheck.instructions.md to understand available rule categories
• [ ] Locate BuildCheck rule implementation files in src/BuildCheck directory
• [ ] Create test suite covering success/failure cases for each diagnostic rule
• [ ] Add integration tests validating BuildCheck behavior across different project types
• [ ] Document each rule with example project files that trigger and pass the check

Add GitHub Actions workflow for validating binary log format compatibility across releases

The repo has a skill file at .github/skills/maintaining-binary-log-compatibility/SKILL.md, but there's no automated CI workflow visible in .github/workflows (inferred as empty). Binary log format changes are breaking changes. Contributors could create a CI workflow that validates new changes don't break backward compatibility with binlogs from previous MSBuild versions.

• [ ] Review .github/skills/maintaining-binary-log-compatibility/SKILL.md for compatibility requirements
• [ ] Identify binary log serialization code in src/Logging directory
• [ ] Create GitHub Actions workflow file (e.g., .github/workflows/binlog-compatibility-check.yml)
• [ ] Implement test matrix validating current build against binlogs from last 3-5 MSBuild releases
• [ ] Add step to run BinLogQuery tool against test binlogs to ensure parser stability
• [ ] Document compatibility testing process in .github/instructions/logging.instructions.md

• Add unit tests for src/Tasks/Microsoft.Build.Tasks/Error.cs and Warning.cs tasks—they lack dedicated test coverage in src/UnitTests/. Start with TaskTestBase pattern used in adjacent task tests.: Small: Understand task parameters, input/output items, and MSBuild.Test.Utilities helpers
• Expand .github/instructions/globbing.instructions.md—it's minimal. Document how Include/Exclude patterns work in Evaluator.cs with concrete examples (e.g., **/*.cs vs *.cs).: Small: Read Evaluator globbing logic, trace property expansion, write documentation with runnable examples
• Add diagnostic command /diag:evaluate to CLI that logs all property evaluation steps in human-readable format (parallel to existing /diag:verbose). Implement in MSBuild.cs and BuildManager.cs.: Medium: Understand logging infrastructure (IEventSource, ILogger), trace evaluation in Evaluator.cs, add new switch parsing

The MSBuild repository demonstrates a reasonable security posture with established CI/CD security practices (Azure Pipelines 1ES templates, Dependabot configuration, GitHub security workflows). However, the analysis is limited by incomplete dependency information and configuration file contents. Primary concerns include: (1) PAT token management in GitHub Copilot actions, (2) potential hardcoded secrets in configuration files, (3) unverified dependency security status, and (4) lack of visibility into specific pipeline security controls. The repository should maintain continuous security scanning and implement automated secret detection. No critical vulnerabilities were identified based on available file structure analysis, but deeper code review is recommended.

• Medium · Copilot PAT Token Exposure Risk — .github/actions/select-copilot-pat/. The repository contains GitHub Copilot integration with PAT (Personal Access Token) selection action (.github/actions/select-copilot-pat). While the action itself appears to be a workflow component, PAT tokens used in CI/CD pipelines require careful secret management. If tokens are logged or exposed in workflows, credentials could be compromised. Fix: Ensure all PAT tokens are marked as secrets in GitHub Actions. Implement comprehensive audit logging for token usage. Use GitHub's secret scanning and rotation policies. Review workflow logs to ensure tokens are never printed or exposed.
• Medium · Potential Secrets in Configuration Files — .config/ directory. The repository contains multiple configuration files (.config/tsaoptions.json, .config/guardian/.gdnbaselines, etc.) that could potentially contain sensitive information. Without inspection, it's unclear if credentials or API keys are embedded in these configuration files. Fix: Audit all configuration files to ensure no credentials, API keys, or sensitive data are hardcoded. Use environment variables or secret management systems for sensitive configuration. Implement pre-commit hooks to scan for secrets using tools like git-secrets or TruffleHog.
• Low · Limited Visibility into Dependency Security — Package dependencies (*.csproj, packages.config, package.json). The dependency file content was not provided in the analysis. MSBuild as a build platform likely has numerous NuGet and npm dependencies that should be regularly audited for known vulnerabilities. Fix: Implement automated dependency scanning using tools like Dependabot (already present in repo), OWASP Dependency-Check, or Snyk. Review the results in .azuredevops/dependabot.yml and .github/dependabot.yml configurations to ensure they are properly configured with appropriate update policies.
• Low · Build Pipeline Security Configuration — .azuredevops/, .github/workflows/. The repository contains Azure Pipelines and GitHub Actions workflows. While security practices appear to be implemented (1ES Pipeline Template, Guardian baseline), the specific security controls in these pipelines are not visible without deeper analysis. Fix: Verify that CI/CD pipelines enforce: (1) Code signing for build artifacts, (2) SAST/DAST scanning, (3) Dependency vulnerability checks, (4) Secure secret handling, (5) Audit logging of deployments. Review .config/1espt/PipelineAutobaseliningConfig.yml for proper security baselining.
• Low · Git Configuration Security — .gitattributes, .git-blame-ignore-revs. Repository contains .gitattributes and .git-blame-ignore-revs files. Without inspection, it's unclear if git configurations properly prevent security-sensitive files from being tracked. Fix: Ensure .gitattributes and .gitignore properly exclude sensitive files (credentials, keys, secrets). Verify that important security-related commits are not in the ignore-revs list. Use git hooks to prevent accidental credential commits.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.