GO — Healthy across the board

• Last commit 1d ago
• 9 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 51% of recent commits

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

Windows Forms (WinForms) is a .NET UI framework for building Windows desktop applications that wraps native Windows user interface libraries (User32, GDI+) with managed code. It provides visual controls, a drag-and-drop designer in Visual Studio, and enables rapid development of stable, complex Line of Business applications on Windows. This repository is the modern .NET (Core 3.0+) fork of the original .NET Framework 4.8 implementation, supporting .NET 6, 7, 8, 9+. Monolithic repository structure: src/ contains the core WinForms managed code wrapping native Windows APIs, organized by functional areas (controls, designers, rendering). The out-of-process Designer is a separate concern mentioned in documentation. Build uses Azure DevOps pipelines (.azuredevops/) and GitHub Actions (.github/workflows/) for CI/CD, with CodeQL static analysis enabled. Extensive test skills documentation (.github/skills/) suggests organized test suites per subsystem (control-api-tests, gdi-rendering-tests).

Windows desktop application developers migrating from .NET Framework to modern .NET, third-party control vendors building custom WinForms controls, and Visual Studio users leveraging the out-of-process WinForms Designer for rapid UI development. Primarily enterprise developers building complex domain-specific workflows and internal tools.

Production-ready and actively maintained. WinForms has been in active use since .NET Framework 1.0 (2002) and this .NET fork is mature with significant CI/CD infrastructure (.azuredevops/, .github/workflows/), comprehensive test infrastructure (evidenced by skills under .github/skills/), and ongoing development. Recent updates include dark mode support for GDI rendering and async/await modernization patterns visible in .github/copilot/ guides.

Low risk for established patterns, but moderate risk for new features and migrations: the codebase explicitly diverged from .NET Framework with breaking changes documented in compatibility guides, third-party control vendors must carefully validate design-time vs. runtime behavior during .NET Framework→.NET migration, and tight coupling to Windows-only APIs (User32, GDI+) means no cross-platform support. Dependency on native Windows libraries and COM interop adds complexity.

Active modernization around dark mode rendering (GDI rendering skill), async/await patterns (Async folder in copilot guides), and code modernization initiatives visible in .github/skills/code-modernization/. The .azuredevops/dependabot.yml and backport workflow (.github/workflows/backport.yml) indicate active dependency management and multi-version release coordination. Recent labeler automation (.github/workflows/labeler-*.yml) suggests improving issue/PR triage.

Clone the repo: git clone https://github.com/dotnet/winforms.git && cd winforms. Check for build scripts in the root (likely CMake, given CMake in file list at 15KB). Install .NET SDK 6+ (inferred from README mentioning .NET 6, 7, 8, 9 support). Run: dotnet build to compile. See CONTRIBUTING.md (.github/CONTRIBUTING.md) for detailed local development setup.

Daily commands: Exact command depends on platform. Windows: dotnet build from root. Run sample: dotnet run --project <path-to-sample-project>. For designer testing, open a .NET WinForms project in Visual Studio 2022 with .NET 6+ SDK installed. Check .github/skills/running-tests/SKILL.md for test execution.

• Winforms.sln — Primary solution file defining all project references and build configuration for the entire Windows Forms framework.
• Directory.Build.props — Central MSBuild properties file that defines common build settings, versions, and dependencies for all projects in the solution.
• Directory.Build.targets — Shared MSBuild targets file specifying common compilation rules, test execution patterns, and output configurations across all projects.
• Directory.Packages.props — Central NuGet package version management file ensuring consistent dependency versions across all projects in the monorepo.
• .github/CONTRIBUTING.md — Contribution guidelines and workflow expectations that all developers must follow before submitting pull requests.
• docs/developer-guide.md — Comprehensive developer onboarding guide covering architecture, design patterns, and common development tasks specific to WinForms.
• CODEOWNERS — File ownership matrix defining code review responsibilities and subject matter experts for different areas of the codebase.

Add a New Control to Windows Forms

1. Review the control inheritance hierarchy and base classes in docs/developer-guide.md to understand required abstract methods and event patterns. (docs/developer-guide.md)
2. Create a new control class inheriting from Control or an appropriate base class, implementing required accessibility via AccessibleObject override. (docs/accessibility/accessible-role-controltype.md)
3. Add GDI+ rendering logic in OnPaint override, following dark mode guidelines documented in copilot instructions. (.github/copilot/GDI/DarkModeButtonRendererCodeGenerationInstructions.md)
4. Register the control in the designer metadata configuration to enable drag-and-drop support in Visual Studio designer. (docs/designer/readme.md)
5. Add unit tests validating control behavior, accessibility mappings, and rendering under different DPI scales. (.github/skills/gdi-rendering-tests/SKILL.md)

Implement Dark Mode Support for a Control

1. Understand the button renderer pattern and dark mode color mapping from the provided code generation instructions. (.github/copilot/GDI/DarkModeButtonRendererCodeGenerationInstructions.md)
2. Modify the control's OnPaint method to detect SystemColors.HighContrast or Application.RenderWithVisualStyles and select appropriate brush/pen colors. (docs/design/anchor-layout-changes-in-net80.md)
3. Test rendering output using GDI+ rendering test infrastructure to validate colors under light, dark, and high-contrast themes. (.github/skills/gdi-rendering-tests/SKILL.md)
4. Update designer preview behavior in net-inproc-designer to reflect dark mode appearance during design-time. (docs/designer/net-inproc-designer.md)

Add a Roslyn Analyzer for WinForms Code Quality

1. Review existing WinForms C# and VB.NET analyzers to understand the diagnostic code structure and conventions used. (docs/analyzers/WinFormsCSharpAnalyzers.Help.md)
2. Create new analyzer class implementing ISyntaxNodeAnalyzer, defining the diagnostic descriptor with ID, title, message, and category. (docs/analyzers/WinFormsCSharpAnalyzers.Help.md)
3. Add analyzer registration to the appropriate analyzer package (C# or VB.NET variant). (docs/analyzers/Experimental.Help.md)
4. Write unit tests using the analyzer testing framework, ensuring false positives are minimized and edge cases handled. (.github/skills/control-api-tests/SKILL.md)

Set Up a New Async Control Method with InvokeAsync Pattern

1. Reference the async pattern guidelines and test instruction generation for proper InvokeAsync method signatures. (.github/copilot/Async/invokeAsync_generate_test_instructions.md)
2. Implement the method using Control.InvokeAsync with proper TaskScheduler context marshaling and error handling. (docs/developer-guide.md)
3. Create unit tests following the async test patterns to validate callback execution, cancellation, and exception propagation. (.github/skills/running-tests/SKILL.md)

• GDI+ graphics — Provides vector graphics rendering, brush/pen effects, and image handling required for cross-platform WinForms controls with high-fidelity visual output.
• Win32/User32 P/Invoke — Enables low-level access to Windows windowing, message handling, and native APIs that form the foundation of the WinForms abstraction layer.
• UI Automation (UIA) — Allows accessibility infrastructure for screen readers, keyboard navigation, and programmatic control discovery required for WCAG compliance.
• MSBuild & NuGet — Provides cross-platform build orchestration, package management, and dependency resolution for multi-targeting (.NET 6+, .NET Framework compat).
• Roslyn analyzers — Enables static code analysis at compile-time to detect WinForms-specific best practices and anti-patterns before runtime.
• Out-of-process designer — Isolates the designer runtime from user application, preventing form loading errors from crashing the entire IDE and allowing independent versioning.

• Out-of-process designer vs in-process designer

  • Why: Isolating designer in separate process improves IDE stability and allows independent updates, but adds inter-process communication overhead and complexity.
  • Consequence: Slower designer startup (~2–5s), but resilient to form deserialization failures that previously crashed Visual Studio.

• GDI+ for rendering vs Direct2D/DirectX

  • Why: GDI+ has broad hardware support and Windows 7+ compatibility, whereas Direct2D requires Windows 7 SP1+ with potential driver issues.
  • Consequence: GDI

Windows-only development: native P/Invoke requires Windows SDK headers; macOS/Linux local builds unsupported. Designer duality: breaking changes exist between .NET Framework Designer and modern out-of-process Designer; third-party control vendors must validate both paths. Async modernization in progress: some APIs still use old callback patterns; check .github/copilot/Async/ before proposing async changes. GDI+ API surface is large and legacy-heavy; dark mode rendering changes (mentioned in DarkModeButtonRendererCodeGenerationInstructions.md) require careful testing across control types.

• P/Invoke (Platform Invocation) — WinForms core mechanism for calling native Windows APIs (User32, GDI+); understanding marshaling, calling conventions, and handle lifecycle is essential for debugging rendering or input issues.
• GDI+ Graphics Pipeline — Primary rendering engine for WinForms controls; knowledge of brush/pen/graphics state management is required for custom control rendering or dark mode support changes.
• Out-of-Process Designer Architecture — Modern WinForms Designer runs separately from the design-time host; breaking changes between in-process (.NET Framework) and out-of-process (.NET) modes affect third-party control vendors and require dual validation.
• Control Hierarchy & Message Pumping — WinForms controls inherit from Control base class and participate in Win32 message loop; understanding window handle lifecycle and message routing is critical for debugging event handling or input issues.
• Visual Design-Time vs. Runtime Duality — Controls must support both design-time (static layout, property serialization) and runtime (dynamic behavior); the out-of-process designer creates two separate execution contexts requiring careful API design.
• Breaking Changes in .NET Migration — This fork explicitly broke compatibility with .NET Framework 4.8 in several areas; reviewing documented breaking changes is mandatory before assuming API equivalence with framework code.
• COM Interop & IDispatch — WinForms controls expose COM interfaces for legacy VB6 compatibility and ActiveX hosting; understanding COM marshaling and variant handling is needed for interop-related bug fixes.

• dotnet/runtime — Core .NET runtime that WinForms depends on; necessary for understanding P/Invoke marshaling and interop layer behavior.
• dotnet/wpf — Parallel modern .NET UI framework (WPF) also forked from .NET Framework; shares CI/CD infrastructure patterns and breaking change documentation approach.
• dotnet/winforms-designer — Separate repository for the out-of-process WinForms Designer for .NET 6+ (mentioned in README); handles visual design experience separate from runtime.
• dotnet/samples — Sample applications demonstrating WinForms usage patterns, useful for understanding real-world control composition and designer workflows.

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 test coverage for GDI+ rendering dark mode functionality

The repo contains GDI rendering instructions in .github/copilot/GDI/DarkModeButtonRendererCodeGenerationInstructions.md and references gdi-rendering-tests in skills, but there's no visible dedicated test suite file for dark mode rendering. WinForms' GDI+ rendering is critical for visual controls, and dark mode support is increasingly important. A new test project with comprehensive unit and visual regression tests for dark mode button rendering would improve quality and serve as a reference implementation.

• [ ] Create src/System.Windows.Forms.Tests/GDI/DarkModeRenderingTests.cs with unit tests for dark mode button states
• [ ] Add visual baseline tests using the gdi-rendering-tests skill pattern referenced in .github/skills/gdi-rendering-tests/SKILL.md
• [ ] Document test patterns in docs/gdi-rendering-tests.md for future dark mode feature additions
• [ ] Reference the existing DarkModeButtonRendererCodeGenerationInstructions.md in test documentation

Implement async/await pattern migration tests for legacy control APIs

The .github/copilot/Async/invokeAsync_generate_test_instructions.md exists as a code generation guide, but there's no visible test suite validating the async invoke patterns. Many WinForms controls have legacy synchronous APIs that need safe async wrappers. Creating a dedicated test suite would ensure async migrations don't introduce race conditions or deadlocks—critical for UI framework reliability.

• [ ] Create src/System.Windows.Forms.Tests/Async/AsyncInvokeTests.cs covering InvokeAsync patterns for standard controls
• [ ] Add threading stress tests to validate no deadlocks occur with concurrent async invocations
• [ ] Add tests validating backward compatibility with legacy Invoke() calls during async migrations
• [ ] Document the async migration pattern in docs/async-patterns.md using examples from the Copilot instructions

Add accessibility API coverage tests for ListView and other complex controls

The repo has docs/accessibility/listview-expected-behavior.md documenting expected ListView accessibility behavior, but no visible corresponding automated test file. Accessibility is critical for enterprise applications and compliance. Creating tests that verify ListViewItemState, role announcements, and control type mappings would prevent regressions and improve confidence in accessibility implementations.

• [ ] Create src/System.Windows.Forms.Tests/Accessibility/ListViewAccessibilityTests.cs validating control types against docs/accessibility/accessible-role-controltype.md mappings
• [ ] Add tests for keyboard navigation, screen reader announcements, and accessible name/description for ListView items and columns
• [ ] Add fixture-based tests for the expected behaviors documented in docs/accessibility/listview-expected-behavior.md
• [ ] Create docs/accessibility/testing-guidelines.md documenting how to test accessibility for new controls using ListView as a reference

• Add dark mode rendering tests for a control not yet covered under GDI rendering tests (check .github/skills/gdi-rendering-tests/ for existing coverage matrix) — involves adding test cases to ensure controls render correctly with system dark mode enabled.
• Convert a legacy callback-based API to async/await following patterns in .github/copilot/Async/ — search src/ for methods using WaitHandle or callback delegates and modernize following the generated guidelines.
• Document breaking changes between .NET Framework and .NET variants in a specific control's API surface (start with a high-use control like Button or TextBox) — extract from CONTRIBUTING.md and populate a new breaking-changes.md in docs/controls/.

The Windows Forms repository demonstrates a reasonable security posture with a clear vulnerability reporting mechanism through MSRC. However, several areas require attention: the SECURITY.md documentation is incomplete, critical configuration files (NuGet.config, build scripts, CI/CD pipelines) require content review, and supply chain security documentation is not visible. The repository appears to follow Microsoft's standard security practices but would benefit from enhanced documentation of security controls, dependency management policies, and explicit security code ownership. No critical vulnerabilities are immediately apparent from the file structure alone, but the absence of visible security scanning configurations and SBOM documentation represents a maturity gap.

• Medium · Incomplete Vulnerability Reporting Documentation — SECURITY.md. The SECURITY.md file instructs users not to open issues for security reports but the sentence is incomplete ('Please do not open issues'). This could cause confusion about the proper reporting procedure and potentially delay security issue reporting. Fix: Complete the security reporting instruction. The statement should clearly explain the process (e.g., 'Please do not open issues for security vulnerabilities. Report them privately via MSRC as described above.').
• Low · Missing CODEOWNERS File Review for Security — CODEOWNERS. While a CODEOWNERS file exists, the provided content does not show its details. Security-sensitive areas (like authentication, cryptography, and data handling code) should have explicit security-focused code owners. Fix: Ensure CODEOWNERS file designates security-conscious reviewers for sensitive components. Consider creating a separate security team designation for critical subsystems.
• Low · Limited Build Security Configuration Visibility — build.cmd, build.sh, azure-pipelines.yml, azure-pipelines-PR.yml. Build configuration files (build.cmd, build.sh, azure-pipelines.yml) are present but their contents are not reviewed. These files could potentially contain insecure build practices, hardcoded credentials, or unsafe build flags. Fix: Review all build and CI/CD configuration files for: 1) Hardcoded secrets or credentials, 2) Insecure artifact handling, 3) Missing security scanning steps, 4) Proper dependency verification.
• Low · NuGet Configuration File Requires Security Review — NuGet.config. NuGet.config file exists but content is not provided. This file could contain unverified package sources, disabled signature validation, or other dependency security issues. Fix: Review NuGet.config to ensure: 1) Only trusted package sources are configured, 2) Package signature validation is enabled, 3) No hardcoded credentials in package sources, 4) Dependency version pinning where appropriate.
• Low · Missing Supply Chain Security Documentation — Repository root. No evidence of SBOM (Software Bill of Materials), dependency scanning documentation, or supply chain security policies in the visible file structure. Fix: Implement and document supply chain security practices: 1) Generate and maintain SBOM, 2) Enable automated dependency vulnerability scanning, 3) Document dependency management policy, 4) Consider sigstore or similar signing mechanisms.

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

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

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/winforms 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.

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

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "dotnet/winforms(\\.git)?\\b" \\
  && ok "origin remote is dotnet/winforms" \\
  || miss "origin remote is not dotnet/winforms (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 "Winforms.sln" \\
  && ok "Winforms.sln" \\
  || miss "missing critical file: Winforms.sln"
test -f "Directory.Build.props" \\
  && ok "Directory.Build.props" \\
  || miss "missing critical file: Directory.Build.props"
test -f "Directory.Build.targets" \\
  && ok "Directory.Build.targets" \\
  || miss "missing critical file: Directory.Build.targets"
test -f "Directory.Packages.props" \\
  && ok "Directory.Packages.props" \\
  || miss "missing critical file: Directory.Packages.props"
test -f ".github/CONTRIBUTING.md" \\
  && ok ".github/CONTRIBUTING.md" \\
  || miss "missing critical file: .github/CONTRIBUTING.md"

# 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/winforms"
  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).

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