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/wpf 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 1d ago
• 13 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 78% of recent commits

_{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/wpf repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/dotnet/wpf.

What it runs against: a local clone of dotnet/wpf — 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/wpf | 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 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of dotnet/wpf. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/dotnet/wpf.git
#   cd wpf
#
# 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/wpf and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "dotnet/wpf(\\.git)?\\b" \\
  && ok "origin remote is dotnet/wpf" \\
  || miss "origin remote is not dotnet/wpf (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"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
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/wpf"
  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).

WPF (Windows Presentation Foundation) is a .NET Core UI framework for building Windows desktop applications with vector-based rendering and XAML-based declarative markup. It provides application models, data binding, controls, graphics, layout, and document support—with native ARM64 support as of .NET 6.0 and active development for .NET 10. Monolithic repository: top-level src/ contains framework code split by feature (Core, Framework, PresentationCore, etc.), with native interop in C++ layers. Build configuration via Directory.Build.props and Directory.Build.targets for centralized MSBuild control. Documentation in Documentation/ with contribution guides and architecture notes. CI/CD defined in .github/workflows/ and azure-pipelines-pr.yml.

Enterprise Windows desktop application developers migrating from .NET Framework to .NET Core, or building new Windows-only desktop apps using C# and XAML. Also targets framework contributors and maintainers working on the .NET ecosystem.

Production-ready and actively maintained. The project is part of the official .NET Foundation (MIT licensed), has CI/CD via Azure Pipelines and GitHub Actions, supports multiple .NET versions (6.0–9.0, with .NET 10 in development), and maintains separate test suites in dotnet/wpf-test. Requires Visual Studio 2022 Preview for development on the latest .NET version.

Low risk for users; WPF is an official Microsoft framework. For contributors: the codebase is large (72M+ C# LOC, 11M+ C++ LOC) with mixed interop complexity, requiring native tooling knowledge. Test coverage is documented as limited ('have limited coverage at this time'). Single-maintainer risk is mitigated by Microsoft sponsorship, but large surface area (controls, rendering, layout, data binding) means breaking changes can impact many applications.

Active development for .NET 10 (stated in README status). Roadmap-driven work with specific component ship dates. Recent additions include ARM64 support (post-.NET 6.0), continued API refinement documented in Documentation/report-on-adding-new-property.md, and test expansion efforts (test repo linked separately). Dependabot configured (.azuredevops/dependabot.yml) for ongoing dependency management.

Clone: git clone https://github.com/dotnet/wpf.git. Requirements: .NET 6.0+ SDK, Visual Studio 2022 Preview for .NET 8.0+ work, and C++ build tools. Run Restore.cmd (Windows batch script in repo root) to restore dependencies and build prerequisites. See Documentation/getting-started.md for detailed environment setup.

Daily commands: Windows only. After Restore.cmd, build via dotnet build Microsoft.Dotnet.Wpf.sln. For testing: separate test repo at dotnet/wpf-test (not inline). No dev server; this is a framework library. Sample WPF apps would be created by developers using the NuGet packages or local builds.

• Directory.Build.props: Central MSBuild properties file controlling build configuration, versioning, and target frameworks for the entire monorepo.
• Directory.Build.targets: Central MSBuild targets file applying build logic, compiler flags, and code generation rules across all projects.
• Documentation/getting-started.md: Primary entry point for environment setup, SDK requirements, and development workflow for contributors.
• Documentation/contributing.md: Contribution guidelines, PR process, code review expectations, and licensing/CLA requirements.
• .github/workflows/main.yml: CI/CD pipeline definition for automated builds, tests, and validation on every PR and commit.
• NuGet.config: NuGet feed configuration for resolving dependencies and pre-release SDK packages.
• Microsoft.Dotnet.Wpf.sln: Primary Visual Studio solution file; entry point for loading and building the framework in the IDE.

Start in src/ for framework code. For UI controls: src/Microsoft.DotNet.Wpf/Framework/System.Xaml/ and src/Framework/System.Xaml.Markup/. For rendering: src/Core/ or native C++ layers under corresponding directories. For data binding logic: search src/ for Binding class implementations. Add tests in dotnet/wpf-test repo (linked separately). Follow Documentation/contributing.md for PR process and Documentation/codegen.md for code generation workflows.

Windows-only build: Restore.cmd and native C++ compilation require Windows and Visual Studio C++ tools; Linux/macOS builds are not supported. Visual Studio 2022 Preview required for .NET 8.0+ development (not released version). XAML compilation is complex—markup compilation output is auto-generated in obj/ and must not be edited manually. ARM64 support is newer (.NET 6.0+); x86/x64 have broader test coverage. Test coverage is deliberately limited (see README); most validation relies on Helix integration tests (Documentation/testing-in-helix.md). Dependency property system requires boilerplate (DependencyProperty.Register calls) that is easy to get wrong.

• XAML (Extensible Application Markup Language) — WPF's entire declarative UI model is built on XAML; understanding XML-based markup, type converters, and namespace resolution is essential for working with the framework.
• Dependency Properties — WPF controls use dependency properties instead of standard C# properties for data binding, animations, and styling support; this is a non-obvious pattern unique to WPF.
• Routed Events — WPF events propagate through the logical tree (tunneling/bubbling) rather than firing on a single element; critical for understanding event handling in complex UI hierarchies.
• Layout Measurement and Arrangement — WPF's two-pass layout algorithm (Measure → Arrange) with infinite constraints is different from traditional imperative layouts; understanding this is essential for custom controls and layouts.
• Vector-Based Rendering (Direct3D/Direct2D Interop) — WPF renders to vector graphics via native Windows APIs (Direct3D, Direct2D), enabling high-DPI scaling without rasterization artifacts; this architecture is why WPF differs from GDI-based frameworks.
• Data Binding and Change Notification — WPF's data binding engine relies on INotifyPropertyChanged and DependencyProperty change notification for two-way binding; the pipeline includes value converters, validation rules, and update triggers.
• C++/CLI Interop with Native Windows APIs — Large portions of WPF's rendering and window management layer use C++/CLI to wrap native Windows APIs (HWND, DirectX); contributors must understand this mixed-language boundary.

• dotnet/winforms — Alternative Windows desktop UI framework for .NET Core; same ecosystem, different design philosophy (Win32-based vs. vector rendering).
• dotnet/wpf-test — Official WPF test suite repository (separate from main repo); required for running and extending automated tests for framework changes.
• dotnet/runtime — Core .NET runtime and base class libraries that WPF depends on; changes to runtime affect WPF compatibility and performance.
• dotnet/xaml-standard — XAML standardization effort and cross-platform XAML dialect specification; informs WPF's XAML implementation roadmap.
• AvaloniaUI/Avalonia — Modern cross-platform XAML framework inspired by WPF; useful for understanding alternative XAML implementations and migration paths.

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 testing guide for Helix test execution in Documentation/

The repo has Documentation/testing-in-helix.md which is referenced in the file structure, but WPF contributors frequently struggle with running tests locally vs. in Helix CI. A new contributor could expand this with concrete examples of: (1) how to run specific test categories locally before submitting, (2) debugging Helix failures with logs, and (3) mapping test projects to Helix queues. This directly supports the PR workflow and reduces back-and-forth on CI failures.

• [ ] Review existing Documentation/testing-in-helix.md and identify gaps
• [ ] Add section: 'Running Tests Locally Before Helix' with specific dotnet test commands for src/ subdirectories
• [ ] Add section: 'Interpreting Helix Failure Logs' with links to azure-pipelines.yml job definitions
• [ ] Create examples for common test projects (e.g., System.Xaml.Tests, WindowsDesktop.Tests)
• [ ] Cross-reference Documentation/developer-guide.md for consistency

Implement automated API compatibility checks in PR validation workflow

Documentation/api-compat.md exists, indicating API compatibility is important, but .github/workflows/main.yml likely doesn't enforce API surface validation on PRs. A new contributor could add a GitHub Action step that: (1) runs the api-compat tooling mentioned in Documentation/gen-api.md against modified assemblies, (2) blocks breaking changes, and (3) surfaces reports as PR comments. This prevents accidental binary-breaking changes from shipping.

• [ ] Review .github/workflows/main.yml and identify where API validation should run
• [ ] Review Documentation/api-compat.md and Documentation/gen-api.md for the actual validation tools/scripts
• [ ] Add workflow step to extract modified assemblies from PR diff
• [ ] Integrate API comparison tool and parse results into PR comment format
• [ ] Test against a sample PR that modifies a public API surface

Create missing integration test scaffold for XAML markup compilation scenarios

Documentation/LocalMarkupCompilation.md exists, but there's no clear test coverage structure for XAML compilation edge cases in the file tree. A new contributor could create a new test project under src/ (e.g., System.Xaml.Compilation.Tests) that covers: (1) local vs. AOT markup compilation, (2) namespace resolution in XAML, and (3) resource reference binding. This addresses a known complex area where bugs regress easily.

• [ ] Review Documentation/LocalMarkupCompilation.md to understand the compilation pipeline
• [ ] Identify existing XAML test infrastructure (likely in src/Microsoft.DotNet.Wpf.GitHub/)
• [ ] Create src/Microsoft.Xaml.Composition.Tests/ project mirroring the main solution structure in Microsoft.Dotnet.Wpf.sln
• [ ] Add 10-15 focused test cases covering scenarios from LocalMarkupCompilation.md
• [ ] Update Directory.Build.props and relevant eng/Testing.targets to include new test project
• [ ] Verify tests run locally and integrate into azure-pipelines.yml

• Add missing XML documentation comments to public API surface in src/Framework/System.Xaml/System/Xaml/XamlReader.cs and related core reader classes—improves IntelliSense and adheres to .NET API guidelines.
• Expand test coverage for the dependency property validation system (src/Framework/System.Xaml/System/Xaml/DependencyPropertyValidator.cs or equivalent)—currently under-tested; write unit tests for edge cases in validation callbacks.
• Document the XAML markup compilation pipeline in Documentation/ with a concrete walkthrough—Documentation/LocalMarkupCompilation.md exists but lacks step-by-step examples of how the codegen process transforms XAML to C#.

The WPF repository demonstrates generally good security practices with MSRC vulnerability reporting process, dependabot configuration, and organized build/signing infrastructure. However, there are several areas requiring attention: (1) The SECURITY.md documentation is incomplete, (2) No explicit security-sensitive code path identification in CODEOWNERS, (3) Limited visibility into dependency scanning automation details, (4) Build script security measures need verification, and (5) Signing process documentation could be more explicit. The codebase appears to follow .NET Foundation standards, but security hardening should be more explicitly documented and visible in the repository structure. No hardcoded secrets, SQL injection risks, or obvious infrastructure misconfigurations were detected in the provided file listing.

• Medium · Incomplete Security Policy Documentation — SECURITY.md. The SECURITY.md file appears to be truncated ('Please do not open issues for anything you thin...'). This incomplete documentation may not fully communicate the security reporting process to potential security researchers, potentially leading to public disclosure of vulnerabilities. Fix: Complete the SECURITY.md file with full instructions. Ensure it clearly states not to open public issues for security vulnerabilities and directs reporters to the MSRC process.
• Low · Missing CODEOWNERS Security Review Specification — .github/CODEOWNERS. While CODEOWNERS file exists, there is no visible specification for mandatory security review approvals or security-sensitive code paths. This could result in security-critical changes being merged without specialized security review. Fix: Define security-sensitive code paths in CODEOWNERS that require explicit approval from security-focused maintainers. Consider areas like: serialization, network communication, cryptography, and input validation.
• Low · No Visible Dependency Scanning Configuration — .azuredevops/dependabot.yml, NuGet.config. While dependabot.yml exists, no comprehensive SBOM (Software Bill of Materials) generation or automated vulnerability scanning configuration is visible in the provided file structure. WPF's UI framework nature makes it a high-value target. Fix: Ensure dependabot.yml has aggressive update policies for security fixes. Consider adding OWASP Dependency-Check or similar tools to the CI/CD pipeline. Generate and maintain an SBOM for releases.
• Low · Build Script Security Hardening Not Visible — build.cmd, build.sh, Restore.cmd, dotnet-test-install.ps1. Build scripts (build.cmd, build.sh, Restore.cmd) are present but their security measures are not visible from the file structure. These scripts execute during the build process and could be attack vectors if not properly secured. Fix: Ensure all build scripts: (1) Validate downloaded dependencies with checksums, (2) Use HTTPS for all remote resources, (3) Avoid shell injections, (4) Document security-relevant steps, (5) Run with minimal required privileges.
• Low · Limited Visibility into Signing Implementation — eng/Signing.props. Signing configuration exists (eng/Signing.props) but the actual implementation details are not visible. WPF being an official .NET repository, proper code signing is critical but requires verification. Fix: Verify that all NuGet packages and assemblies are signed with Microsoft's official key. Ensure signing happens in secure build environments only. Document the signing process in the security documentation.

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.