Oh wait for it. It's not the final version - I am still working on that.
I also will go through the doc first and decapitalize!

(German muscle memory strikes again! 😃)

Run the prepareTemplates.bat batch file.

I got this:

I suggest to change:

like that:

 dotnet new -u Microsoft.WinForms.Designer.TypeEditorTemplate 
 dotnet pack 
 dotnet new -i .\bin\Debug\Microsoft.WinForms.Designer.TypeEditorTemplate.1.1.0-prerelease-preview3.nupkg 

This is what caused me confusing when I first read, and after I build templates too:

PropertyTypeName
Type Editor Name

why is there a single number? This is very basic scenario, on practice you often will get several editors and plenty of properties in a single control...
I described my thoughts about this, in relation to winforms-datavisualization, in more detail here.

why is there a single number?

Not sure entirely what you mean, but I guess 4.7.2?
Yes, that is a specific target version (for now), because that's what Visual Studio TFM is.
Remember, you are not providing your controls for Framework and for .NET at the same time. These templates are only to provide the controls for .NET (from version 6 including onwards). The fixed 4.7.2 assembly version is ONLY to run the Framework parts of the Designer for the .NET 6 control in the context of Visual Studio.

And yes, I think I'll take your suggestion, and then merge it back into my repo here (I am currently working in a Microsoft repo which is still private, but I'll ping you first as soon as we're open that up.), so you can test it.

Also, I'll continue discussing this with my boss @merriemcgaw today, and I think including the migration steps from a Framework based Type Editor makes perfect sense. I'd adapt a Framework version of this sample then, and we should include the important steps to go - with the help of the template - from Framework to .NET.

Not sure entirely what you mean, but I guess 4.7.2?

PropertyTypeName
Type Editor Name

I meant it should be plural - not single PropertyTypeName and not single TypeEditorName, but enumeration of several PropertyTypeNameS and several TypeEditorNameS.

This is very basic scenario, on practice you often will get several editors and plenty of properties in a single control...

---UPD---

Oh, I created a project according to the provided templates... I can admit that I was completely baffled. I thought the Type Editor Template is the actual template prototype for any new control that needs a custom designer 🤦‍♂️ But in fact it turned out that this is a template for your test (example) project 🙄
I thought that the whole article is dedicated to the template, that with its help it is much easier to create a project for controls with a custom designer. And with the help of this template, the test application was created...
May I ask, why did you need to make a template for a test (training) project? It totally blew me away 😰

It's not the sample project. It's something more basic a general.
The sample project was the Tile Repeater. This is just a simple Type Editor Dialog, which serves as a starting point for your own adaptation. Without a complete implementation of a simple type editor, how would you approach creating a new type editor?

Also I think one Type Editor per new template should be enough. If we add another Type Editor, we would need to add I think at least 10 additional class files, and I don't think that would add clarity.

Again, I can offer you a 1:1 via teams or zoom, to take your most pressuring questions offline, if you like. I think I can quickly explain where most of the confusion comes from.

In addition: It doesn't generate a test project. It only generates the skeleton of what's absolutely necessary to implement ONE type editor for ONE custom control. You will ALWAYS need 5 projects for ONE type editor, but you can then comparatively easy add additional controls and their respective type editors into those projects.

I missed to push a commit, sorry, my bad.
Please try this, it should be better.

@KlausLoeffelmann Now I think I've got the point :)

Again, I can offer you a 1:1 via teams or zoom, to take your most pressuring questions offline, if you like. I think I can quickly explain where most of the confusion comes from.

I think now there is definitely no need for this, I will slowly understand the projects received from the templates and try to adapt them to the chart...

At the moment the general gist is clear. I have only one question (non critical):

I totally do not understand how it (winforms-datavisualization) manages to work now being in one .net6 project? Perhaps understanding this, it will be possible to come up with some kind of temporary workaround?

Thank you once again, I hope to provide you with my feedback as I progress :)

I totally do not understand how it (winforms-datavisualization) manages to work now being in one .net6 project?

I am not sure I understand the question fully.
Let me try to think where I need to provide better info to make things clearer.

You would provide the NuGet package which the template generated for a .NET 6 project.
And then your app would use only the Control Library (which is also .NET) at runtime.
The NuGet package you provide contains the Designer Part all right, but also the custom control(s), so, the pure .NET 6 Control Library.

So, when you include the NuGet project which the template generates in a .NET 6 WinForms app, it just "takes" the control library (which is also targeting .NET) and uses it. And yes, the NuGet also contains the .NET Framework parts, and the Protocol (standard library), and the .NET 6 Designer Assembly - all of which are not used at runtime.

Please keep the questions coming!
The questions you have are good! If you have them, others will have them, too.
So, I will try to take the essence of them into account in the blog post I am working on!

Thanks,

Klaus

I am not sure I understand the question fully.

winforms-datavisualization (with custom designer and many custom editors) port is pure .Net6, one dll control. Which I compiled under the new designer SDK, slightly correcting and commenting out non-working things - that's all! And the new VS (up to 17.4) designer works with this control (if referenced by dll)! how can it be? If editors must be compiled for net472?

VS 17.4 is still targeting ("written in") Framework 4.7.2.
And only the Type Editor part is targeting 4.7.2.
But it's never needed at runtime.

And the new VS (up to 17.4) designer works with this control (if referenced by dll)! how can it be?

Some things are delegated behind the scenes:

• Action Lists
• CodeDom Serializers
• Type Converters
• Some (Drop Down) Editors (which are essentially TypeEditors).

Modal-Dialog-Type-Editors won't work. If you can show them at all, they will crash or hang Visual Studio.

There is a new version of the readme - considerably extended, also based on your question. Please re-read it. I guess it will answer most of your additional questions.

here is a new version of the readme - considerably extended, also based on your question. Please re-read it. I guess it will answer most of your additional questions.

Modal-Dialog-Type-Editors won't work. If you can show them at all, they will crash or hang Visual Studio.

In readme of this PR I found only this:

Since the modern WinForms Designer runs out of the Visual Studio process for showing most of the design-time experience, type editors for complex types need to be migrated so that they can cooperate with the new realities of the modern WinForms Designer.

In main readme I found this:

1. If you just have a UI, which is based on a type-converter and therefore shown in the context of the Property grid (like Enums or dedicated items to show in a property grid’s property grid cell ComboBox), your UI will be supported by the new designer model out of the box.

2. If you have a UI, which is part of the control (like custom painted adorners or Action Lists), then you would need to write your control library against the WinForms Designer SDK, but you don’t need to roundtrip data to the Server process. Everything from the Developer’s perspective seems to actually be done server-side, and you can reuse most of the existing Control Designer Code, but just need to target it against the Windows Designer SDK.

3. If you have custom type editors, however, which are displaying dedicated modal dialogs, then there is some rewriting effort involved for roundtripping the required data between the two processes.

p1. is ok. In p2. I think italic part need a bit more clarification. And p3. is about modal dialogs again.

So we make conclusion that complex types are types that need modal dialogs in editing...

These dialogs are definably modal:

And they've been working great (without any crash or even error) for almost a year now...
There is clearly some kind of misunderstanding / understatement here. 🤔

Did the CallOffer or DataPoint classes/structs have EditorAttributes in the Framework version - so, do they bring their own Type Editors? Or did the Editors work there intrinsically?

Did the CallOffer or DataPoint classes/structs have EditorAttributes in the Framework version - so, do they bring their own Type Editors? Or did the Editors work there intrinsically?

[
SRCategory("CategoryAttributeChart"),
SRDescription("DescriptionAttributeChart_Series"),
Editor(typeof(SeriesCollectionEditor), typeof(UITypeEditor)),
DesignerSerializationVisibility(DesignerSerializationVisibility.Content),
]
public SeriesCollection Series
{
    get
    {
        return _dataManager.Series;
    }
}

[
SRCategory("CategoryAttributeData"),
Bindable(true),
SRDescription("DescriptionAttributeSeries_Points"),
DesignerSerializationVisibility(DesignerSerializationVisibility.Content),
Editor(typeof(DataPointCollectionEditor), typeof(UITypeEditor))
]
public DataPointCollection Points
{
    get
    {
        return _points;
    }
}

And they are both (and several others) derived from:

internal class ChartCollectionEditor : CollectionEditor {}

:

internal class DataPointCollectionEditor : ChartCollectionEditor {}
internal class SeriesCollectionEditor : ChartCollectionEditor {}

Did you compare the behavior of the Collection Editors from Framework and the last working version of .NET? My suspicion here is that the custom editors did not get pulled it. Rather, the out-of-process Designer tried to provide its own collection editor functionality as well as it was able to. But then it may hit a spot, where customization was needed. It could have been pure luck, that it was somehow working before, but also probably never the way it was intended to work.

I have currently no time to investigate that thoroughly, but maybe I can manage to take a quick look later this week.

You would need to figure out, why custom collection type editors were needed to begin with. What are they doing that the intrinsic editors cannot do? If we need to implement a custom collection type editor for each type, that would be even more effort, unfortunately. There is also a sample ("Sophisticated") in this repo, showing, how custom collection editors are implemented. In a nutshell, you would need to provide additional functionality via Endpoints for the Collection operations like Add, Delete, Edit... .

But, to be honest, there is a lot of assuming here. Let's take the time to get behind it.

Also, Collection Editors will not be covered in the first part of the blog post. We need to get this basic information out first, and then we aim with the second part in the first quarter of next year. The reason is, we're thinking about steps to easing up the necessary boiler plate coding, especially for Collection Editors.

I took a quick look:
Setting up a Chart-Series, for example, is a comparatively complex functionality in the old Framework editor. There is a dedicated SeriesCollectionEditor for that. I am pretty sure that that wasn't the Editor you saw in the working version.

I took a quick look: Setting up a Chart-Series, for example, is a comparatively complex functionality in the old Framework editor. There is a dedicated SeriesCollectionEditor for that. I am pretty sure that that wasn't the Editor you saw in the working version.

.Net472:

.Net6

The only difference is that some custom properties don't have a color/picture icon. From here it follows that the GradientEditor does not work in .Net6 (it does not work on the properties of the chart itself too). This is also a good question - why (in my understanding it's p.1 may be p.2)? And of course why almost all of CollectionEditor inheritors - work???

OK, give me quick pointer, so I don't need to browse all the threads:
Which version of Visual Studio/the WinForms Designer does work again, and from which on not anymore.

And also, which branch from which repo again should I get?

Never mind, I got it.

I'll post it anyway so it's in one place.
Repo to test: https://github.com/kirsan31/winforms-datavisualization/tree/dev
Draft blind port to new designer commit: kirsan31/winforms-datavisualization@17698a2
Designer was working in all versions of V.S. from 17.0 to 17.4 Preview 1. And was broken in 17.4 Preview 2.
Also this very strange serialization bug (toward the end of the post, the reason causing this bug is described) was always there.

Yes. It's in the chart serializer, where the Designer finds and instantiates the serializer on the server-side as expected but then can't call it's Serialize method. I am testing a few things around this today.