WinForms Designer Regression: Cannot Select EnableDesignMode-Exposed Panel by Click in .NET 9

[Overdrive77]

Environment

Summary

In WinForms .NET 9: (Version 17.14.10)
When building a custom UserControl that exposes an internal panel with 'EnableDesignMode', it is not possible to select this internal panel by clicking in the designer. All drag-and-drop operations add controls to the root UserControl, not the design-surface-exposed panel, unless the Document Outline is used.

This worked as expected in .NET Framework 4.8.1, where clicking the internal panel selected it for control drops.
In .NET 9, this is broken and makes composite control design much harder.

---

Minimal Repro

Steps to Reproduce

1. Add the following minimal UserControl and designer to a .NET WinForms project:

   using System.ComponentModel;
   using System.Windows.Forms;
   using System.Windows.Forms.Design;
   
   [Designer(typeof(DemoPanelDesigner))]
   public class DemoPanel : UserControl
   {
       private readonly Panel _contentPanel = new Panel();
   
       public DemoPanel()
       {
           _contentPanel.Dock = DockStyle.Fill;
           this.Controls.Add(_contentPanel);
       }
   
       [Browsable(true)]
       [DesignerSerializationVisibility(DesignerSerializationVisibility.Content)]
       public Panel ContentPanel => _contentPanel;
   }
   
   public class DemoPanelDesigner : ParentControlDesigner
   {
       public override void Initialize(IComponent component)
       {
           base.Initialize(component);
   
           if (component is DemoPanel panel)
               EnableDesignMode(panel.ContentPanel, nameof(DemoPanel.ContentPanel));
       }
   }

2. Build the project, open a Form in the designer, and add 'DemoPanel' to it.

3. Try to drag a Button (or any control) and drop it inside the 'DemoPanel' surface.

4. Observe the generated code:

   // Result:
   demoPanel1.Controls.Add(this.button1); // added to UserControl.Controls, not ContentPanel.Controls

5. Open Document Outline (View > Other Windows > Document Outline), select 'ContentPanel', and add a Button again.

6. Observe that it is now correctly added to the internal panel.

Expected Behaviour

Clicking inside a design-surface-exposed internal panel should select it, and controls dragged in should be added to that panel, not the root UserControl.

Actual Behaviour

• Clicking in the designer surface always selects the UserControl itself.
• Controls are always added to the root Controls collection, even when clicking inside the exposed sub-panel.
• Only by selecting the sub-panel in Document Outline can controls be added correctly.

Why this Matters

• Breaks the designer experience for any composite/custom controls.
• Causes confusion, misplaced controls, and wasted developer time.
• No obvious fix/workaround except using Document Outline, which is not discoverable or intuitive for most developers.

Environment

• .NET 9 (also occurs in .NET 6/7/8, .NET Framework 4.8.1)
• Visual Studio 2022 v17.10.x

Workarounds Tried

• Using Document Outline: works but is not intuitive.
• Custom designers/overrides: no effect.
• Runtime logic: not relevant for design-time code.

Suggested Solution

• Support hit-testing/selecting 'EnableDesignMode' sub-controls by mouse click in the designer.
• At least provide an option or shortcut to route drop/selection to the correct design surface.

---

Thank you for considering!

.NET version

.NET 9

Did this work in a previous version of Visual Studio and/or previous .NET release?

.NET Framework 4.8.1

Issue description

When building a custom UserControl that exposes an internal panel with EnableDesignMode, it is not possible to select this internal panel by clicking in the designer. All drag-and-drop operations add controls to the root UserControl, not the design-surface-exposed panel, unless the Document Outline is used.

Steps to reproduce

1. Add the following minimal UserControl and designer to a .NET WinForms project:

using System.ComponentModel;
using System.Windows.Forms;
using System.Windows.Forms.Design;

[Designer(typeof(DemoPanelDesigner))]
public class DemoPanel : UserControl
{
    private readonly Panel _contentPanel = new Panel();

    public DemoPanel()
    {
        _contentPanel.Dock = DockStyle.Fill;
        this.Controls.Add(_contentPanel);
    }

    [Browsable(true)]
    [DesignerSerializationVisibility(DesignerSerializationVisibility.Content)]
    public Panel ContentPanel => _contentPanel;
}

public class DemoPanelDesigner : ParentControlDesigner
{
    public override void Initialize(IComponent component)
    {
        base.Initialize(component);

        if (component is DemoPanel panel)
            EnableDesignMode(panel.ContentPanel, nameof(DemoPanel.ContentPanel));
    }
}

2. Build the project, open a Form in the designer, and add `DemoPanel` to it.
3. Try to drag a Button (or any control) and drop it inside the `DemoPanel` surface.
4. Observe the generated code:

### Diagnostics

```text

[Epica3055]

this is actually not an issue.

you can add this to your project

  <ItemGroup>
    <PackageReference Include="Microsoft.WinForms.Designer.SDK" Version="1.6.0" />
  </ItemGroup>

and modify your namespace

public class DemoPanelDesigner : Microsoft.DotNet.DesignTools.Designers.ParentControlDesigner

---

The reason behind this:

For .Net winform designer development, we use another approach, which is different from .Net framework winform designer development.

These two blogs will aid your understanding and your further development.

https://devblogs.microsoft.com/dotnet/state-of-the-windows-forms-designer-for-net-applications/

https://devblogs.microsoft.com/dotnet/custom-controls-for-winforms-out-of-process-designer/

[Overdrive77]

Thanks for the response, but calling this “not an issue” seriously underestimates the real-world impact.

Let’s be absolutely clear: this is an issue — just not one you’re owning.

The Facts:
• In .NET Framework, ParentControlDesigner + EnableDesignMode worked reliably.
• In .NET 9, it silently fails — no compiler warning, no design-time error, no actionable feedback.
• Developers are left with broken drag-and-drop behaviour and no indication why.
• The “fix”? Manually add an undocumented SDK and switch to a renamed namespace buried in dev blogs.

That’s not a “new model.” That’s a break in established functionality with zero discoverability.

This Isn’t Evolution — It’s Regression

You’ve replaced a working, well-understood system with a fragile one that requires undocumented changes and hidden dependencies — without a migration guide, tooling hints, or official documentation to support it.

The Developer Contract Is Broken

You can’t promote open-source transparency and developer trust while moving critical design-time behaviour behind obscure SDKs and expecting devs to find them by accident.

If the design model has changed, that’s fine — but communicate it clearly.

This isn’t about clinging to old habits. It’s about respecting developer time, consistency, and mental bandwidth.

Bottom Line

If functionality that worked for 15+ years now requires a hidden SDK, renamed types, and an entirely different mental model just to function — that is an issue.

[Overdrive77]

Apologies if my earlier comment came off as a rant — I’m just speaking from a place of long-standing frustration.

Ever since .NET MAUI was introduced, the overall quality of Visual Studio’s tooling — particularly around designer support and cross-platform workflows — has clearly deteriorated. Visual Studio used to feel like a powerhouse: stable, intuitive, and productive.

Now? It feels like we’re constantly fighting against the very tools that are supposed to help us. Basic design-time functionality that’s worked for years is either broken, hidden behind obscure packages, or reimplemented with incomplete documentation.

I say this not to criticise for the sake of it, but because I want Visual Studio and the .NET ecosystem to be as strong as it used to be — and right now, it’s just not there.