Suggested Feature: Designer Support for Missing Event Handlers

[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.

[KlausLoeffelmann]

I am thinking about this idea, and in general, I think this is worth considering to improve the experience, because I share the sentiment: This is really an annoyance. If we want to solve it the proposed way ... maybe. But we should think definitely consider this.

But @LeafShi1 is absolut correct - this has nothing to do with the Runtime.
Everything you mentioned would be purely a Designer-side feature implementation.

But I get it - what else should you do!? 😸
Since the Designer is not open source, this is the right place to suggest it!
We just need to frame it differently.

@Olina, could you put that on the Designer backlog?
@LeafShi1, could you change the framing of this issue, so it becomes a suggestion for a new Designer feature?

Thanks!

[diegoxd12wee436]

Hi @KlausLoeffelmann and @LeafShi1 👋
Thank you so much for the explanation and the correction! I'm really sorry for the confusion, I was partially using a translator (right now too) and formulated my original message wrong :'0 .

To reframe it correctly: My idea is purely an IDE Quick Action (the light bulb 💡) for the WinForms Designer. I don't want to change any C# compiler rules or downgrade the CS1061 error.

When the IDE detects a CS1061 error on an event subscription in the .designer.cs file, the Quick Action would simply offer 2 options:

1. 🗑️ Remove the designer subscription (delete the += line).
2. 🛠️ Create the empty handler method.

[ArcadeMakerSources]

@LeafShi1
I've checked the partial method solution - subscribing a non-implemented partial method is perfectly valid - the subscription will just be removed, no compiling errors, which is exactly what we want:

public partial class Program
{
    static event System.EventHandler<string> OnLoad;
    static partial void Greet(object sender, string e);

    public static void Main(string[] args)
    {
        OnLoad += Greet;
        OnLoad(null, "Ben");
    }
}
public partial class Program
{
    static partial void Greet(object sender, string e)
    {
        Console.WriteLine($"Hello, {e}!");
    }
}

// Output: Hello, Ben!

[Olina-Zhang]

@Olina, could you put that on the Designer backlog?

Put it in our internal designer backlog: https://github.com/microsoft/winforms-designer/issues/6703.

[diegoxd12wee436]

Suii XD thankss that'll be so useful

[LeafShi1]

I've checked the partial method solution - subscribing a non-implemented partial method is perfectly valid - the subscription will just be removed, no compiling errors, which is exactly what we want:

The sample shows that partial methods are technically capable of handling this scenario. However, the problem appears to be an orphaned Designer event subscription rather than an event-handler declaration problem. It may be more appropriate to treat this as a Designer experience enhancement (detect/recreate/remove missing handlers) instead of changing the code-generation model for all Designer-generated events.