Partial methods as controls events

[ArcadeMakerSources]

Background and motivation

Currently, when you have a control, say a button, in the visual form designer, and you double-click it, it generates a normal method in the the MyForm.cs file, such as:

private void button_Click(object sender, EventArgs e)
{

}

And in MyForm.designer.cs it just adds

this.button.Clicked += new EventHanlder<EventArgs>(this.button_Click);

Now, if you will remove this method, it will cause a designer error, and you'll have to go to the designer code and manually delete this line. For beginners it's especially problematic...

I think that a better approach would be to generate partial method, and add its signature in the designer:

this.button.Clicked += new EventHanlder<EventArgs>(this.button_Click);
...
partial void button_Click(object sender, EventArgs e);

This way, if you will delete the method implementation, it won't be an error.

API Proposal

partial class Form1 : Form
{
    private partial void Button1_Click(object sender, EventArgs e)
    {

    }
}

API Usage

Form1.designer.cs:

private void InitializeComponent()
{
    ...
    this.Button1.Clicked += new System.EventHandler<System.EventArgs>(this.Button1_Click);
}

private Button Button1;
private partial void Button1_Click(object sender, EventArgs e);

Alternative Designs

No response

Risks

No response

Will this feature affect UI controls?

The VS designer will need to generate event methods as partial methods.

[LeafShi1]

Thanks for the suggestion — I can see the motivation here, especially in trying to make the experience more forgiving when removing event handlers.

However, I’m not sure partial methods would address the underlying issue in a way that fits well with the current WinForms and C# design model.

Today, the behavior is consistent with how the designer works:

• Event subscriptions are generated in the designer file (Designer.cs).
• The handler method is a normal method defined in user code.
• If the method is removed while the subscription remains, the code becomes invalid — and the resulting error is expected, as it reflects a mismatch between the two.

In this model, removing an event handler is intended to be done through the designer (or by removing the subscription), rather than by deleting the method implementation alone. This keeps the generated code and user code in sync.

Regarding partial methods:

Partial methods are primarily a compile-time feature. If no implementation is provided, the method is removed entirely by the compiler. However, event subscriptions require a concrete delegate target:

this.button1.Click += this.Button1_Click;

If the method is not present, the subscription is still invalid. Because of that, switching to partial methods would eliminate the error scenario being described.

More broadly, the designer today relies on explicit and deterministic code generation. Event bindings are represented as concrete += assignments, and behavior isn’t inferred based on method presence or absence. Introducing implicit behavior (e.g., “no implementation means no handler”) could make the generated code harder to reason about and debug.

[diegoxd12wee436]

I have an idea is basically a Roslyn analyzer that shows a warning (not an error) when an event subscription in Designer.cs has no matching handler and then provides a quick action (light bulb) with 2 options:

✅ Remove the designer subscription – deletes the += line from .designer.cs

❌ Create the empty handler method – generates the missing method stub automatically

and that will be so usefull sometimes I accidentally double click a button and I have to do that whole process of deleting from the designer XD.

[LeafShi1]

I have an idea is basically a Roslyn analyzer that shows a warning (not an error) when an event subscription in Designer.cs has no matching handler and then provides a quick action (light bulb) with 2 options:

Thanks for the suggestion — I understand the motivation around improving the workflow for accidental event handler generation.

However, this would fundamentally change the expected behavior of event wiring in C#. An event subscription is compiled as a strongly-typed delegate binding: this.button1.Click += this.button1_Click;

The compiler must resolve the target method at compile time. If the method does not exist, this results in CS1061: "'Type' does not contain a definition for 'methodName'"， this is enforced by the C# compiler.

So the current behavior is not accidental — it is part of the language’s type safety guarantees. Downgrading this from an error to a warning would weaken correctness and allow invalid delegate bindings to compile.

The scenario described is primarily a usability issue, but it shouldn’t drive a change in core language semantics.