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/xceedsoftware/wpftoolkit 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.

WAIT — Slowing — last commit 8mo ago

• Last commit 8mo ago
• 3 active contributors
• Other licensed
• ⚠ Slowing — last commit 8mo ago
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 90% of recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ No CI workflows detected
• ⚠ No test directory detected

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

What it runs against: a local clone of xceedsoftware/wpftoolkit — 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 xceedsoftware/wpftoolkit | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 272 days ago | Catches sudden abandonment since generation |

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

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

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

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

# 4. Critical files exist
test -f "ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/AeroTheme.cs" \\
  && ok "ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/AeroTheme.cs" \\
  || miss "missing critical file: ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/AeroTheme.cs"
test -f "ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Xceed.Wpf.AvalonDock.Themes.Aero.csproj" \\
  && ok "ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Xceed.Wpf.AvalonDock.Themes.Aero.csproj" \\
  || miss "missing critical file: ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Xceed.Wpf.AvalonDock.Themes.Aero.csproj"
test -f "ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Metro/MetroTheme.cs" \\
  && ok "ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Metro/MetroTheme.cs" \\
  || miss "missing critical file: ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Metro/MetroTheme.cs"
test -f "ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Theme.xaml" \\
  && ok "ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Theme.xaml" \\
  || miss "missing critical file: ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Theme.xaml"
test -f "ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Controls/SplineBorder.cs" \\
  && ok "ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Controls/SplineBorder.cs" \\
  || miss "missing critical file: ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Controls/SplineBorder.cs"

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

Extended WPF Toolkit is a comprehensive collection of missing WPF controls, components, and utilities for building professional Windows desktop applications. It fills the gaps in the native WPF framework with production-ready controls like advanced DataGrid, RichTextBox, ColorPicker, DateTimePicker, and AvalonDock-based docking panel systems. With over 1 million downloads, it's the de facto standard complement to Microsoft's WPF for enterprises building feature-rich Windows applications. Monolithic multi-project structure under ExtendedWPFToolkitSolution/Src/ with separate assembly projects per feature: Xceed.Wpf.AvalonDock (docking framework), Xceed.Wpf.AvalonDock.Themes.Aero, Xceed.Wpf.AvalonDock.Themes.Metro (theme packages with XAML resources in Theme.xaml), and core toolkit assemblies. Each theme module (Aero, Metro) contains theme-specific XAML brushes and control templates plus supporting C# code (AeroTheme.cs, AeroColors.cs) and PNG image assets for toolbar buttons and dock indicators.

C# and .NET developers building enterprise Windows desktop applications using WPF who need advanced UI controls (DataGrids, Ribbons, Docking managers, Pickers) without reinventing them from scratch. Target users include financial software developers, IDE builders, CAD applications, and line-of-business Windows apps that require professional-grade control libraries.

Highly mature and production-ready. The project has over 1 million NuGet downloads, spans multiple .NET framework versions (NET35 through NET5+ based on .csproj files), and maintains a consistent release cadence (v5.0.0 released September 2025, v4.7.0 in March 2025). The codebase shows institutional discipline with community licensing and a Plus Edition subscription model for commercial support.

Low technical risk for core functionality, but vendor lock-in to Xceed's closed-source Plus Edition for advanced features and professional support. The free Community License (v4.0.0+) is non-commercial only, creating legal risk for proprietary use unless upgrading to Plus Edition. WPF itself is a legacy platform (no longer the primary Microsoft desktop UI framework, with WinUI/MAUI ascendant), so long-term platform sustainability depends on enterprises maintaining WPF applications.

Active maintenance with v5.0.0 released September 9, 2025 (3 bug fixes/improvements), v4.7.0 released March 10, 2025 (19 improvements), and parallel Plus Edition track at same versions with additional features. The project maintains dual releases: free Community version and commercial Plus Edition with 6-8 week release cycle.

Clone the repository, then open ExtendedWPFToolkitSolution as a Visual Studio solution. Build the solution to compile all projects. For NuGet usage: dotnet add package Extended.Wpf.Toolkit (free Community Edition) or purchase Plus Edition for commercial use. Pre-built binaries are in ExtendedWPFToolkitSolution/Libs/ for reference.

Daily commands: Open ExtendedWPFToolkitSolution.sln in Visual Studio 2019 or later (supports .NET 5 projects based on .NET5.csproj files). Build > Build Solution. No external service dependencies. For consuming the toolkit: add NuGet reference Extended.Wpf.Toolkit to your WPF application project and import XAML namespaces like xmlns:xctk="http://schemas.xceed.com/wpf/xaml/toolkit".

• ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/AeroTheme.cs — Core theme implementation that defines the Aero visual style; essential for understanding how themes are structured and applied across the toolkit.
• ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Xceed.Wpf.AvalonDock.Themes.Aero.csproj — Primary project file defining dependencies, assembly configuration, and build targets; required for setting up the build environment.
• ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Metro/MetroTheme.cs — Alternative theme implementation showing the theme abstraction pattern; demonstrates extensibility for adding new visual styles.
• ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Theme.xaml — Master XAML resource dictionary defining brushes, styles, and control templates; the visual contract for the Aero theme.
• ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Controls/SplineBorder.cs — Custom control demonstrating the pattern for creating specialized UI elements with smooth borders; foundational for advanced theming.
• ExtendedWPFToolkitSolution/Libs/READ_ME.txt — Documents external dependencies and .NET framework support (NET35, NET5); critical for understanding version compatibility and assembly requirements.

Add a New Theme

1. Create new folder under ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.YourTheme/ (ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/)
2. Copy and customize AeroTheme.cs as YourTheme.cs with custom color constants (ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/AeroTheme.cs)
3. Create Theme.xaml and Brushes.xaml with your color palette, referencing the Aero templates as base (ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Theme.xaml)
4. Create or provide custom Images/ folder with docking and pin icons in your theme style (ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Images/)
5. Duplicate Xceed.Wpf.AvalonDock.Themes.Aero.csproj and update AssemblyName, namespace, and embedded resources (ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Xceed.Wpf.AvalonDock.Themes.Aero.csproj)

Customize Docking UI Icons

1. Locate the theme's Images/ folder matching your target theme (Aero, Metro, or VS2010) (ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Images/)
2. Replace PNG files for docking positions (DockAnchorableBottom.png, DockDocumentLeft.png, etc.) with your custom icons (ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Images/DockAnchorableBottom.png)
3. Update pin/menu icons (PinAutoHide.png, PinClose.png, PinMaximize.png, etc.) with variants for light, dark, and black backgrounds (ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Images/PinAutoHide.png)
4. Ensure all images are embedded resources in the .csproj and referenced in Theme.xaml ImageBrush definitions (ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Xceed.Wpf.AvalonDock.Themes.Aero.csproj)

Extend Theme Color Scheme

1. Open the theme's AeroColors.cs (or equivalent) to view current color constants (ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/AeroColors.cs)
2. Add new Color properties for additional UI states (e.g., HoverColor, DisabledColor, SelectionColor) (ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/AeroColors.cs)
3. Update Brushes.xaml to define new SolidColorBrush resources using the new color constants (ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Brushes.xaml)
4. Apply new brushes to control templates in Theme.xaml for consistent theming (ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/Theme.xaml)

Community License restriction: free version (v4.0.0+) is non-commercial only—proprietary/for-profit products must purchase Plus Edition. WPF platform legacy: Windows-only, no cross-platform support, declining mindshare vs. WinUI/MAUI. Assembly versioning: separate NET35 and NET5 builds in Libs/ folder; ensure correct version referenced in your project. Theme customization: modifying Brushes.xaml requires full solution rebuild and assembly redeployment—hot-reload may not work. Strong naming: assemblies are signed with sn.snk; custom builds must resign.

• XAML Theming & Resource Dictionaries — The toolkit's Aero and Metro themes are entirely XAML-based resource dictionaries (Brushes.xaml, Theme.xaml); understanding how WPF merges and applies ResourceDictionary entries is essential to customizing or extending themes
• WPF Attached Behaviors & Dependency Properties — Advanced controls in the toolkit use attached properties extensively for configuration (especially AvalonDock's layout serialization); mastering these is required to integrate controls into complex MVVM applications
• Strong Name Assembly Signing — The toolkit uses sn.snk key files (visible in each project) to create strong-named assemblies for GAC registration and version binding; essential for enterprise deployments and preventing assembly spoofing
• Control Template Customization — WPF controls (DataGrid, DatePicker, etc.) in the toolkit are styled via control templates in XAML; customizing appearance requires understanding ControlTemplate, VisualState, and Storyboard animations
• Docking Panel Layout Serialization — AvalonDock (the docking framework core in the toolkit) serializes pane layouts to preserve user workspace state; understanding its XML serialization format is critical for persistence features in enterprise apps
• Multi-Targeting & Framework Compatibility — The toolkit maintains separate builds for NET35, NET Framework, and NET5+ (visible in csproj files); understanding conditional compilation and platform-specific APIs ensures controls work across .NET versions
• Value Converters & Type Coercion — Complex WPF controls like DataGrid and ColorPicker rely on IValueConverter implementations for data binding; the toolkit heavily uses converters for type translation between UI and business logic

• xceedsoftware/wpftoolkit — This is the repository itself—canonical source for Extended WPF Toolkit
• AvalonDock/AvalonDock — Upstream docking panel framework that Extended WPF Toolkit extends with themes and additional features
• microsoft/WPFSamples — Microsoft's official WPF samples and patterns documentation; reference for WPF best practices used in toolkit
• MaterialDesignInXAML/MaterialDesignInXamlToolkit — Complementary WPF UI kit providing Material Design theme alternative to Aero/Metro themes in Extended WPF Toolkit
• dotnet/wpf — Microsoft's open-source WPF core framework; Extended WPF Toolkit builds on top of this foundation

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 unit tests for AvalonDock theme rendering (Aero and Metro)

The repo contains theme assemblies (Xceed.Wpf.AvalonDock.Themes.Aero and Xceed.Wpf.AvalonDock.Themes.Metro) with XAML-based Brushes.xaml and Theme.xaml files, but there's no visible test coverage for theme application, brush color consistency, or control rendering. New contributors could add WPF-specific unit tests to verify theme loading, brush resource resolution, and visual correctness across both themes.

• [ ] Create ExtendedWPFToolkitSolution/Tests/Xceed.Wpf.AvalonDock.Themes.Tests (or similar)
• [ ] Add tests for AeroTheme.cs and AeroColors.cs color palette validation
• [ ] Add XAML-based brush resource loading tests for both Aero and Metro themes
• [ ] Test SplineBorder.cs rendering in both theme contexts
• [ ] Verify no missing image resources (Dock*.png, Pin*.png files exist and load)

Create .NET 5+ build verification and modern framework CI workflow

The repo contains both .NET Framework (.csproj) and .NET 5 (.NET5.csproj) project files (e.g., Xceed.Wpf.AvalonDock.Themes.Aero.csproj and Xceed.Wpf.AvalonDock.Themes.Aero.NET5.csproj), but there's no visible GitHub Actions workflow to verify both build targets compile successfully. This is critical for a 1M+ download library to maintain cross-framework compatibility.

• [ ] Create .github/workflows/dotnet-build.yml for multi-target framework validation
• [ ] Add build steps for net35, net45, net5.0, and net6.0+ targets
• [ ] Run against all .csproj files in ExtendedWPFToolkitSolution/Src
• [ ] Add NuGet package compatibility checks using dotnet pack
• [ ] Test on Windows agents (WPF is Windows-only)

Document theme customization and resource override guide for AvalonDock themes

The theme projects contain numerous XAML resource files (Brushes.xaml, Theme.xaml) and theme classes (AeroTheme.cs, AeroColors.cs) but there's no specific documentation file explaining how developers can customize themes or override brushes. This is a gap for a toolkit focused on UI customization.

• [ ] Create ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/THEME_CUSTOMIZATION.md
• [ ] Document all color properties in AeroColors.cs with their visual purpose
• [ ] Explain XAML brush resource structure in Brushes.xaml and how to override
• [ ] Add code examples showing how to apply custom theme colors programmatically
• [ ] Repeat for Metro theme with its own THEME_CUSTOMIZATION.md

• Add comprehensive unit test suite for AeroColors.cs color utility methods—currently no test coverage visible in file list for color calculation logic used by themes
• Document the AvalonDock docking layout serialization format and create migration guide for users upgrading between major versions (implied by v4→v5 releases)
• Create example WPF applications in an Examples/ folder demonstrating each major control (DataGrid, RichTextBox, Ribbon, AvalonDock, Pickers) with MVVM patterns and data binding scenarios

The Extended WPF Toolkit codebase has moderate security posture. The primary concern is the exposure of the strong name key file (sn.snk) in version control, which is a critical asset that should never be committed. Additionally, the lack of a formal security policy and potential dependency management gaps present medium-level concerns. The presence of outdated .NET 3.5 support is a low-priority issue. No SQL injection, XSS, or credential hardcoding vulnerabilities were identified in the accessible file structure. Recommended immediate actions: (1) remove sn.snk from git history, (2) establish a formal security.md policy, and (3) implement dependency lock files.

• Medium · Strong Name Key File Exposed in Repository — ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/sn.snk. The file 'sn.snk' (strong name key file) is present in the repository at ExtendedWPFToolkitSolution/Src/Xceed.Wpf.AvalonDock.Themes.Aero/sn.snk. This cryptographic key file should never be committed to version control as it can be used to forge signed assemblies and compromise the integrity of the toolkit. Fix: 1. Remove sn.snk from the repository immediately using 'git rm --cached sn.snk' and force push. 2. Add '*.snk' to .gitignore. 3. Consider regenerating the strong name key pair in a secure, non-shared location. 4. Review git history to ensure the key was not exposed in previous commits.
• Low · No Dependency Lock File Detected — Root directory / Package management configuration. The provided dependency file content is empty, suggesting there may be no explicit dependency lock file (packages.lock.json, paket.lock, etc.) in the repository. This makes it difficult to guarantee reproducible builds and track exact dependency versions. Fix: 1. Implement a dependency lock mechanism appropriate for the project (e.g., packages.lock.json for NuGet). 2. Commit lock files to version control to ensure reproducible builds. 3. Regularly audit and update dependencies for security patches.
• Low · Outdated Framework Targets Detected — ExtendedWPFToolkitSolution/Libs/NET35. The codebase includes .NET Framework 3.5 assemblies (.NET35/WPFToolkit.dll), which is an end-of-life framework version released in 2007. While this may be for backward compatibility, it increases the risk of unpatched vulnerabilities. Fix: 1. Document the necessity of supporting .NET 3.5. 2. Consider deprecating .NET 3.5 support in future major versions. 3. Ensure .NET 5+ support is the primary distribution channel (as evidenced by the .NET5.csproj files). 4. Communicate EOL timeline to users.
• Low · Missing Security Documentation — Root directory. No SECURITY.md or security policy file is evident in the repository structure, which limits users' ability to responsibly report security vulnerabilities. Fix: Create a SECURITY.md file that includes: 1. Instructions for responsible vulnerability disclosure. 2. Security contact information. 3. Expected response timelines. 4. Supported versions receiving security updates.

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.