WinForms Designer SDK FAQ, Best Practices, News and Roadmap.

[bairog]

.NET 5/6 has an out-of-process WinForms Designer and docs for its SDK were promised for the first quarter of 2022:

There is a breaking change difference in how Designers work in Framework and .NET, so neither is this a bug, nor is it supposed to work this way.

To create a Designer for VS and .NET, you would need to use the WinForms Designer SDK. The reason is (simplified), that the Designer needs to run in the context of the Form (or the UserControl), which is .NET and not Framework. But VS is Framework. So, for the .NET Designer, there are two processes: The Client Process (Visual Studio, Framework) and a dedicated Server process (.NET) which is called the DesignToolsServer. So principally, and depending on what you need to do, you'd need to provide a NuGet which VS picks up, which holds the code for both the Server and the Client Process. And since the control and most part of the Designer logic is created in the Server process, anything Dialog-UI related needs to be marshalled from the Server process, which is not supposed to handle any dialogs due to potential dead lock concerns, back to the VS-Client.

Docs for the SDK are in the making, they are on our roadmap for the first quarter of this year.
Originally posted by @KlausLoeffelmann in #4451 (comment)

@KlausLoeffelmann First quarter of 2022 is over. Are docs for .NET WinForms Designer SDK ready?

[janseris]

The whole idea of this out-of-process designer for .NET Core (5/6) is terrible because it doesn't work properly in real use cases. I am glad to hear about any updates on it, as well.

[merriemcgaw]

@bairog , @janseris , We're working on those docs, but they're taking a bit longer than expected. We'll be getting them out to everyone as soon as we can, I promise 😄

@janseris - we didn't have any other choice as far as making an out of process designer for .NET 5+ apps. Previously WinForms Designer was running in the same process as VS, devenv.exe, which runs on .NET Framework. We had to pull the designer out into it's own .NET 5(or whatever is targeted) process and create a communication channel back to the .NET Framework process that is VS.

[janseris]

@merriemcgaw meanwhile I discovered that it might be the VS Professional version instead of Community (I am always working on the latest previe of VS 2022) working well or the problem lies solely in third party control vendors (DevExpress) designer because I have created very complicated layout without using any DevExpress controls in a new WinForms project to test this again and surprisingly everything worked very smoothly.
Thank you and your team for all your work on WinForms.
I will test this again with DevExpress controls soon.

[bairog]

@bairog , @janseris , We're working on those docs, but they're taking a bit longer than expected. We'll be getting them out to everyone as soon as we can, I promise 😄

@merriemcgaw Hope you will drop us a link as soon as docs (or at least a part of them) will be ready.
Also tagging @chris-steema as this docs will help him with .NET 5.0 OnCreateHandle override isn't called issue #4451 (and me personally is waiting for a fix in his awesome charting control library 😄)

[KlausLoeffelmann]

@bairog: Good news is, a really comprehensive demo for the SDK is 99% complete. I am in the process of documenting it, and it covers

• Simple (Server-only) Control Designers, which don't have a custom UI (Custom Type Editors), so they "only" need the SDK-ref to work like before with the most common scenarios (Adorners, Actions). Editors based on Type Converters will be possible with that (they wouldn't even need a SDK reference). Custom CodeDom Serializers are possible in this scenario, also (although they will be demo'd in the next scenario).
• Client/Server Control Designers, for Designers which have a custom UI. Those will need to have a Client, a Server, a Protocol and Package Project next to the actual Control library. The resulting assemblies (.NET Framework and .NET) need to be packed in a NuGet, and then picked up by the Designer for design time purposes. Here, we'll cover custom adorner painting, actions, Server-side type-discovery, Custom Collection Editors, Custom Type Editors, CodeDomSerializers and CollectionCodeDomSerializers. Custom Editors here is the biggest and most considerable breaking change which will need effort to rewrite existing Designers, but it's necessary to avoid deadlocks between the (.NET Framework based) Visual Studio process and the (.NET based) Server Process, which shows and manages the actual control at Design time.

We've decided to go public with that sample and a blog post first, so that folks will be able to start migrating, even with the docs not completed. Then, we'll be adding to the docs over time.

As soon I will be able to provide further info, I'll make sure to post them here.

[kirsan31]

The resulting assemblies (.NET Framework and .NET) need to be packed in a NuGet, and then picked up by the Designer for design time purposes.

This part raises the most questions... If I have a local control - can I do without nuget?

[KlausLoeffelmann]

What do you mean by local control?

[RussKie]

I presume scenarios here could be:

• a developer is building a control, and that control is located in the same project as a form, where this control is hosted, and
• a developer is building a control, and that control is located in another project within the same solution.

[KlausLoeffelmann]

Ah, OK, yes, that makes sense.

Well, if your Control Library includes controls that need a dedicated UI via custom Type Editors, then you are required to pack into a NuGet. The reason is, that the Client part needs to be loaded in the context of VS, and the Server part into the context of the DesignToolsServer. If not, so, if the Control needs let's say just custom adorners, action lists or custom CodeDom serializers, then no. You still need to build the Control Designers against the SDK, though, and you should have it in a dedicated project. But as soon as you need a custom UI for a Control Designer of the Library, those three assemblies/four projects, so the Client Part, the Server Part, the code for RPCs from Client to Server and the Packaging become a requirement.

[kirsan31]

Well, if your Control Library includes controls that need a dedicated UI via custom Type Editors, then you are required to pack into a NuGet.

Yes, this is exactly what I was afraid of :( But let's hope this is the worst thing that awaits us 😆

[KlausLoeffelmann]

While the work on the blog post is in progress, the complete SDK docs will take a while due to a shift in internal prios.
We know you're eager for sample code and starting points, so please take a look here for an early access to our SDK sample candidate:

https://github.com/KlausLoeffelmann/NetControlDesigners

[kirsan31]

@KlausLoeffelmann
I've spend some time on studying this. My thots / questions:

• At this moment everything are very confusing. The most problems I faced are absent of editors ArrayEditor, ColorEditor, FileNameEditor etc. And their methods for override EditValue, ShowHelp, CreateCollectionForm etc. The code itself for these overridden methods looks very simple in my case. Do I need to go the hard way?
• Another funny fact is that if you decide to abandon the .net framework and migrate an old project to a new designer (.net), you need to write a client in .net framework! I understand the reason behind this, BUT It evokes a sense of betrayal any way.
• All of this somehow does not inspire optimism 😥 Maybe it will become easier when the full documentation appears? 🤷‍♂️ And examples of converting old projects is defiantly needed.
• When reference a control by project reference and adding it from toolbar to the form, the exception appears (when reference a control by dll reference - all work good).

exception

Failed to create component 'Chart'.  The error message follows:

'Microsoft.DotNet.DesignTools.Client.DesignToolsServerException: Method not found: 'System.CodeDom.CodeExpression Microsoft.DotNet.DesignTools.Serialization.CodeDomSerializerBase.SerializeToExpression(System.ComponentModel.Design.Serialization.IDesignerSerializationManager, System.Object)'.

   at Microsoft.DotNet.DesignTools.Client.DesignToolsClient.<SendRequestAsync>d__49`1.MoveNext()

--- End of stack trace from previous location where exception was thrown ---

   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

   at Microsoft.VisualStudio.Threading.JoinableTask.CompleteOnCurrentThread()

   at Microsoft.VisualStudio.Threading.JoinableTask`1.CompleteOnCurrentThread()

   at Microsoft.DotNet.DesignTools.Protocol.Endpoints.DesignToolsEndpoints.DesignerHostsImpl.CreateComponent(SessionId sessionId, TypeIdentity type, String name, NameValuePairs defaultValues)

   at Microsoft.WinForms.DesignTools.Client.Toolbox.WinFormsToolboxItem.CreateComponentsCore(IDesignerHost host, IDictionary defaultValues)

   at System.Drawing.Design.ToolboxItem.CreateComponents(IDesignerHost host, IDictionary defaultValues)

   at Microsoft.DotNet.DesignTools.Client.Designers.ParentControlProxyDesigner.CreateTool(ToolboxItem tool, IComponent parent, Nullable`1 location, Nullable`1 size, ObjectProxy toolboxSnapArgs)'

[merriemcgaw]

Maybe it will become easier when the full documentation appears? 🤷‍♂️ And examples of converting old projects is defiantly needed.

Yes, we're hoping it will make things a lot easier. And we will be investigating ways to simplify the building of controls as well as converting old controls. It's a process for sure.

[KlausLoeffelmann]

The most problems I faced are absent of editors ArrayEditor, ColorEditor, FileNameEditor etc. And their methods for override...

They are still part of both the .NET and the .NET Framework runtime, although those types as a base for derived Editors in a Server-only scenario don't make sense, since they are never deployed: The .NET types cannot run in the context of VS, and the .NET Framework types lack the infrastructure to be deployed in a server-only scenario. What you can do though in a server-only scenario is to invoke the client-types. In this case the communication between Server (the DesignToolsServer) and Client (Visual Studio) is handled automatically in the background, but only for the respective data types. So, for just using the existing editors, you currently need to include their assembly qualified type names with the Editor attribute for the respective property, and you should be good to go. Like this as an example, to enable a FileNameEditor for any property of type string:

        [Editor("System.Windows.Forms.Design.FileNameEditor, System.Design, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a",
                "System.Drawing.Design.UITypeEditor, System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")]
        public string? Filename { get; set; }

Now, if you want to change the behavior of one of those editors in any way (or create new ones completely from scratch). then, yes, those editors must be running in the context of the Client. As long as you don't change the data types they are handling, you can just modify the editors in an assembly that targets the same TF version as the client, and the rest should work out of the box. But also yes, in that case your overridden types need to be loaded into the context of VS, and so you'd need to have the NuGet package deployment for that in place, even if you - in most cases - would not need to implement or change the underlaying communication between the DesignToolsServer and the client. Except you're handling different types.

Can you, just for my own understanding of the use case, provide a description of what part of the editor you want to change and to what end? That would be helpful!

[...] BUT It evokes a sense of betrayal any way

Can you clarify what you mean? What confuses me is that strong statement of yours, while you write at the same time "I understand the reason behind this".

For a bit more explanation, and that may be helping also in the understanding of our motivation to do this, because this enormous effort that we're doing with rewriting the Designer is really, really not out of some "arbitrary good idea" someone from our team had. It's a real and urgent necessity: Because we are not only addressing the .NET/.NET Framework type-resolution problem with it, so that VS runs in the context of .NET Framework and cannot resolve types from a WinForms .NET app. Rather, we cannot change but need to address the fact that Visual Studio is only one Framework and one Bitness at a time. (So, 64-Bit and .NET Framework in the case of Visual Studio 2022.) Out of that fact, please be clear about this: We will also take the Framework Designer out of process to address the problem, that we cannot - for example - host certain 32-Bit-only .NET Framework components in the 64-bit-.NET-Framework-process running Visual Studio 2022+. So, the whole effort we're doing here does not have anything to do with abandoning any .NET (Framework) version over another. On the contrary! This is a rewrite to make sure, that no matter what bitness and version Visual Studio runs in, it will always be able to host any completely different bitness/.NET version combination of the WinForms app it's providing the Designer for!

The documentation will certainly help to understand this better, but to finalize the documentation in a somewhat sane time frame, it needs more than just me working on that, so, we will be publishing not in one peace, but more and more of it over time.

And all this said - please, by any means:
Those questions of yours are really, really helpful for us and for others, and I appreciate your contribution and engagement A LOT! Please, keep those questions coming!

Best

Klaus