DocumentDesigner class is not implemented. What support to expect for custom hosting of Windows Forms designer?

[ezolotko]

In .NET Core 3.1, DocumentDesigner class from System.Windows.Forms.Design.dll has all of its methods implemented as new NotImplementedException(SR.NotImplementedByDesign);

The DocumentDesigner class is vital for custom hosting of Windows Forms designer in user applications. Judging from the class' .NET Framework implementation, it contains a lot of "glue" root designer logic, common for all document designers.

Will this class and other classes required for custom designer hosting be implemented in .NET Core? What is the Microsoft's stated direction regarding the Windows Forms designer custom hosting features in .NET Core?

A variety of applications use this Windows Forms feature at the moment. They include report designers, application-specific data entry form designers, and others.

[weltkante]

Will this class and other classes required for custom designer hosting be implemented in .NET Core?

I didn't get around to port our own design surfaces yet but 3rd party designer hosting scenarios previously had github issues reported and resolved so I'd assume they are working. I'd expect custom design surfaces like report designers to work (which aren't directly related to designing Forms/UserControls, just using the same infrastucture).

What is the Microsoft's stated direction regarding the Windows Forms designer custom hosting features in .NET Core?

I don't know of official statements, but they previously ported missing parts required for custom designer hosting on a "on demand" basis as they were reported on github. If you have a scenario which fails and can argue for it then it was getting ported. I don't know if just saying "this class is vital" is enough though, since there are differences for 3rd party design surfaces (like report designers) and hosting the Form/Control designer itself.

You'll probably have to present more information about the scenario which isn't working / you want to have supported.

[ezolotko]

@weltkante To illustrate my point, I created a minimal form designer hosting example project. You can download it from here: DocumentDesignerNotImpl.zip It simply creates a design surface and loads a default form.

The project has two targets: netcoreapp3.1 and net452. When you run it with net452 target, it displays a proper design surface:

When you run it with netcoreapp3.1, you get the following error message:

I hope this will make my questions more clear.

[weltkante]

Well, this is just hosting the stock Form/Control Designer. Microsoft is moving this out of WinForms into VS, so I have no idea if they are going to still support this (I'd certainly not be surprised if they don't).

It is a very different use case than hosting a report designer or other custom designer though, in those scenarios you are providing various implementations of your own and I'd expect the infrastructure around the designer to still work (or be fixed). Seems this is not your use case though so the issue description may be dramatizing a bit. (And if you were just looking for "full compatibility" with Desktop Framework, this is definitely and intentionally not the goal, they've already taken plenty incompatibility with Desktop at this point.)

Anyways, thats just my assessment of the situation, we've got to wait for an official response from the team.

[merriemcgaw]

@weltkante is right on with his assessment. Can you tell us a bit about what you're trying to accomplish and I can get back to you with whether or not this is planned to be supported. If we're missing something that devs need we're certainly open to bringing them up to Core.

[wjk]

@merriemcgaw I was thinking on using the WinForms designer as a base for creating a GUI designer for MSI dialogs for use with WiX. I was planning on writing this designer as part of a standalone app (i.e., not a VS extension), so I could put it on the Windows Store. Being able to use the WinForms designer as a base would make my work on the MSI designer much easier, as the only real difference between the two are the contents of the Properties pane and the format written out to disk. Thanks!

[ezolotko]

@merriemcgaw We develop commercial products in a form of component libraries that allow using C#/VisualBasic/TypeScript scripts in .NET application, so it can be extended with custom logic. Sometimes users want to define UI for these scripts, such as option dialogs, etc, and we've implemented our Form Designer using interfaces from System.Windows.Forms.Design such as IDesignerHost, IDesignerEventService, etc. It all works nicely for .NET framework, however we can't get it to work for .NET core.

[merriemcgaw]

@OliaG and @RussKie we should talk about this in our next sync. I don't have an update at this time, and we need to consult some internal folks to make a determination

[wjk]

If we are going to implement this proposal (as appears to be the case given the 6.0 milestone and https://github.com/dotnet/winforms/issues/4456#issuecomment-775640379), we should also go through the design assembly and remove all other references to NotImplementedByDesign. This is currently present in the Glyph and BodyGlyph classes, possibly among others.

[RussKie]

I'm looking at this piece of work, but it isn't straight forward as it may seem.

[RussKie]

Tracking the progress in https://github.com/dotnet/winforms/issues/4456.

[RussKie]

The ported functionality will be available in .NET 6.0 Preview5. Please raise new issues for any further missing functionality. The sooner we know the higher change we get it addressed before .NET 6.0 GA. Thanks

[Lydia-Shi]

Verified this issue with .Net 6.0.100-preview.5.21276.15 from Release/6.0.1XX-preview5 branch of https://github.com/dotnet/installer, it is fixed, results as below:

[yevgeni-zolotko]

We tried it, and it looks like the functionality ported to .NET 6 works for us. Thank you.