CustomToolStrip Not Selectable & Smart Tag not shown in .NET Core Designer

[NagarajManimaran]

When you need a Custom Control Designer in .NET for your control, the NETFX-way to implement that no longer works for .NET.

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

The behavior you see, is by design.

Originally posted by @KlausLoeffelmann in #13232

[NagarajManimaran]

Thank you for the clarification regarding the .NET designer changes and the limitations of using the NETFX-based approach.

Given that the current behavior is by design, could you please let us know if there is any alternative solution or recommended workaround to enable designer support.

If any sample or documentation is available for implementing such support using the new Microsoft.DotNet.DesignTools model, we’d greatly appreciate it.

[Tanya-Solyanik]

@NagarajManimaran - are you able to see https://github.com/microsoft/winforms-designer-extensibility

[NagarajManimaran]

@Tanya-Solyanik Yes, we’ve already tried the Client-Server approach mentioned in the winforms-designer-extensibility repository. While it works as expected in .NET Core/.NET, it does not behave properly in the .NET Framework for the previously mentioned issues.

Could you please advise if there is any way to make it compatible with both .NET Core and .NET Framework, or if the designer support is only intended for .NET Core going forward?

[Shyam-Gupta]

@NagarajManimaran As described in this blogpost, WinForms out-of-process designer provides a limited support for .NET Framework projects. It is mainly intended to support those customers who are using custom controls present in legacy 32-bit assemblies which cannot be loaded by 64-bit Visual Studio. By default, VS will use in-process designer for .NET Framework projects. It will use out-of-process designer only when it detects UseWinFormsOutOfProcDesigner property in the current project configuration.
Again, note that the out-of-process designer for .NET Framework project is not at par with the in-process designer. The custom controls available for .NET Framework projects, which do not use the new extensibility model, will not work properly in the out-of-process designer.

Our recommendation to customers is to use the in-process designer for .NET Framework projects and out-of-process designer for .NET projects. So, the new extensibility model should be used for .NET projects only. However, if you have any requirement to use the new extensibility model for .NET Framework projects, then the project must have UseWinFormsOutOfProcDesigner property defined in current project configuration to work properly.

[merriemcgaw]

If you have specific issues implementing controls for the OOP designer, please feel free to raise these issues. There isn't anything actionable for the team here at this point so I'm closing this issue.

[NagarajManimaran]

@Shyam-Gupta please share the samples or documentation to check and implement the mentioned cases.

[NagarajManimaran]

@Shyam-Gupta

Additional information

We are encountering a designer load failure when using a custom ToolStripEx control in a .NET Core WinForms project. The error is displayed in the Output window under the "WindowsForms" pane as shown below:

[17:01:44.584149] fail: Could not determine a valid designer type for '"RootNamespaceName".CustomToolStripDesigner, "AssemblyName"'.
For information on how to troubleshoot the designer refer to the guide at https://aka.ms/winforms/designer/troubleshooting

This issue occurs when adding our custom ToolStripEx into our RibbonControl.

We have implemented a CustomToolStripDesigner, which uses reflection to load System.Windows.Forms.Design.ToolStripDesigner inside its Initialize method. We believe this reflection-based approach is not functioning correctly in .NET Core, which results in the designer not initializing as expected.

In .NET Framework, this same reflection logic works correctly. As a result, the custom ToolStripEx behaves like the standard ToolStrip, supporting selection, smart tags, and full designer integration.

However, in .NET Core, the reflection appears to fail silently, which causes the designer to skip initializing CustomToolStripDesigner, leading to missing selection behavior and the absence of the smart tag.

We have already created a separate query for the selection and smart tag issue in .NET Core:
#13232 (comment)

It seems both issues are related to reflection not functioning as expected in .NET Core for designer initialization.