dotnet-winforms
Windows Forms
Trigger On
- working on Windows Forms UI, event-driven workflows, or classic LOB applications
- migrating WinForms from .NET Framework to modern .NET
- cleaning up oversized form code or designer coupling
- implementing data binding, validation, or control customization
Workflow
- Respect designer boundaries — never edit
.Designer.csdirectly; changes are lost on regeneration. - Separate business logic from forms — use MVP (Model-View-Presenter) pattern. Forms orchestrate UI; presenters contain logic; services handle data access.
// View interface — forms implement this public interface ICustomerView { string CustomerName { get; set; } event EventHandler SaveRequested; void ShowError(string message); } // Presenter — testable without UI public class CustomerPresenter { private readonly ICustomerView _view; private readonly ICustomerService _service; public CustomerPresenter(ICustomerView view, ICustomerService service) { _view = view; _service = service; _view.SaveRequested += async (s, e) => { try { await _service.SaveAsync(_view.CustomerName); } catch (Exception ex) { _view.ShowError(ex.Message); } }; } } - Use DI from Program.cs (.NET 6+):
var services = new ServiceCollection(); services.AddSingleton<ICustomerService, CustomerService>(); services.AddTransient<MainForm>(); using var sp = services.BuildServiceProvider(); Application.Run(sp.GetRequiredService<MainForm>()); - Use data binding via
BindingSourceandINotifyPropertyChangedinstead of manual control population. See references/patterns.md for complete binding patterns. - Use async/await for I/O operations — disable controls during loading, use
Progress<T>for progress reporting. Never block the UI thread. - Validate with
ErrorProviderand theValidatingevent. CallValidateChildren()before save operations. - Modernize incrementally — prefer better structure over big-bang rewrites. Use .NET 8+ features (button commands, stock icons) when available.
flowchart LR
A["Form event"] --> B["Presenter handles logic"]
B --> C["Service layer / data access"]
C --> D["Update view via interface"]
D --> E["Validate and display results"]
Key Decisions
| Decision | Guidance |
|---|---|
| MVP vs MVVM | Prefer MVP for WinForms — simpler with event-driven model |
| BindingSource vs manual | Always prefer BindingSource for list/detail binding |
| Sync vs async I/O | Always async — use async void only for event handlers |
| Custom controls | Extract reusable UserControl when form grows beyond ~300 lines |
| .NET Framework → .NET | Use the official migration guide; validate designer compatibility first |
Deliver
- less brittle form code with clear UI/logic separation
- MVP pattern with testable presenters
- pragmatic modernization guidance for WinForms-heavy apps
- data binding and validation patterns that reduce manual wiring
Validate
- designer files stay stable and are not hand-edited
- forms are not acting as the application service layer
- async operations do not block the UI thread
- validation is implemented consistently with ErrorProvider
- Windows-only runtime behavior is tested on target
References
- references/patterns.md - WinForms architectural patterns (MVP, MVVM, Passive View), data binding, validation, form communication, threading, DI setup, and .NET 8+ features
- references/migration.md - step-by-step migration from .NET Framework to modern .NET, common issues, deployment options, and gradual migration strategies
More from managedcode/dotnet-skills
dotnet-entity-framework-core
Design, tune, or review EF Core data access with proper modeling, migrations, query translation, performance, and lifetime management for modern .NET applications.
12dotnet-signalr
Implement or review SignalR hubs, streaming, reconnection, transport, and real-time delivery patterns in ASP.NET Core applications.
10dotnet-modern-csharp
Write modern, version-aware C# for .NET repositories. Use when choosing language features across C# versions, especially C# 13 and C# 14, while staying compatible with the repo's target framework and `LangVersion`.
10dotnet-web-api
Build or maintain controller-based ASP.NET Core APIs when the project needs controller conventions, advanced model binding, validation extensions, OData, JsonPatch, or existing API patterns.
9dotnet-roslynator
Use the open-source free `Roslynator` analyzer packages and optional CLI for .NET. Use when a repo wants broad C# static analysis, auto-fix flows, dead-code detection, optional CLI checks, or extra rules beyond the SDK analyzers.
9dotnet-reportgenerator
Use the open-source free `ReportGenerator` tool for turning .NET coverage outputs into HTML, Markdown, Cobertura, badges, and merged reports. Use when raw coverage files are not readable enough for CI or human review.
8