Missing DesignSurface in VS2022 Designer Extensibility support for net6.0-windows Windows Forms controls
ilCosmico opened this issue · 8 comments
With reference to this issue, I have read the paragraph “Migrating existing Control Designers with almost no effort” of this article, but I am having trouble building my custom ControlDesigner in .NET6 due to the absence of the DesignSurface class. Let me explain in detail. (I already tried with NET7, but the issue still persists).
My MyControlDesigner class uses a derived Form class called VisualControlDesigner to display an additional popup for customizing the user control.
(Picture shows it in action in a .NET Framework project)
It internally uses a class called DesignSurfaceExt, which is derived from System.ComponentModel.Design.DesignSurface.
However, I cannot locate it in .NET6, as shown in the following image.
Moreover, MyControlDesigner class uses some adorners, which is not an issue, as demonstrated in the following picture.
To help you understand it better, here is a short video demonstrating both Adorners and Visual Control Designer in action in a NetFramework project: https://www.screencast.com/t/ZIdrCvojT9d.
I saw the video, and was impressed by the sophistication of this Designer. At the same time, these are the scenarios which in all honesty need - let's put it this way: the most love to port to the Out-Of-Proc Designer.
While I don't have the complete picture yet why you might need DesignSurface for that implementation, the fact is that the DesignSurface you will ultimately end up with, FWIW, will be the Framework version, simply, because there is no .NET equivalent that would even come to any deployment.
Everything which is UI-related need to be done in the context of .NET Framework and the VS process. So, there will be no rendering on the Serverside, except for the actual control's content and the adorners. So, the Designer Frame, the Behavior service along with the Adorner Overlay and then the actual Designers, which become part of that whole tree when needed. But that bunch of Windows (all being created in the .NET Server Process) get parented - tadah! - to the Client Process based on DesignSurface (and others in betweem). In the .NET process, there is a) no DesignSurface and b) the (modal WinForms TypeEditor-based) Dialogs cannot be kicked of from the .NET Server but only from the .NET Framework Client Process.
For that particular scenario that means some adaptation work: Type Discovery, of course, needs to be done server-side, because Framework does not have "access" to the .NET type information. If .NET is needed to actually render something in particular, then the only way to that is render the result into a Bitmap's HDC, and then request that Bitmap from the respective (Client-side-shown) TypeEditor from the Server. Same is true for everything, which needs to be presented for example in a TreeView Client-side, which only the Server knows about: That information needs to be collected on the server, and then send back to the client, which then can present it in the TypeEditor's dialog.
Hope this helps as a starting point - keep the questions coming!
PS: And just out of curiosity: What's the product's name you're developing/porting?
(@JeremyKuhne, @lonitra, @merriemcgaw, @Shyam-Gupta FYI)
@KlausLoeffelmann DesignSurface seems to be included in .NET as described here. Why I cannot use it on the Serverside?
Please check out this additional video, which focuses on the .Net Framework version of our component. The video demonstrates the many interactions between the Visual Control Designer and the custom control. You'll notice that every inner element of the custom control is customizable, and the Visual Control Designer picture is updated in real-time. Our approach is similar to the one used by DesignSurfaceExt, which is showcased in this sample. The DesignSurfaceExt has a method CreateControl to interact in real-time with a control. Currently, we're using it to make the Visual Control Designer work.
Here is a NET6 sample project showing a very very simplified control. Is it possible to have a version of this project that shows how to use the DesignSurface in the Client to achieve a similar result as in .Net Framework?
P.S. Product is Eyeshot. You can download a copy here if you need to make some tests on .Net Framework designer.
Why I cannot use it on the Serverside?
Because there is no DesignSurface instance in the Server process. Yes, there is that class in .NET, but it is at this point just a "per se" port from Framework, should we (Microsoft/WinForms) ever need it in a client scenario. So, if we decided, we would like to port Visual Studio to .NET (8+) from .NET Framework (4.7.2), THEN we'd to need to use that class. But, also, THEN we would no longer use the Framework's implementation of that class, and the same problem came up for each respective .NET Framework version of a Designer you would need to support from a .NET Visual Studio client. Does that make sense?
Please read this blog post to understand the interaction between Visual Studio as a Client and the DesignToolsServer of the WinForms Designer in the WinForms Designer context.
Hope that clears things up!
Please read this blog post to understand the interaction between Visual Studio as a Client and the DesignToolsServer of the WinForms Designer in the WinForms Designer context.
You should know that I already read it more than once. You also included it in the issue where you requested me to open this one to provide me with better assistance. However, I am still having difficulty achieving my goal.
If it is not too much trouble, would you mind adding some code to the NET6 sample project I shared to help me better understand?
Thank you for your help in advance.
Unfortunately, I don't have the time at this point to ramp-up in that sample project.
But maybe we can compromise by drilling down in little steps to the area, where we can do a better explanation job, to get you unblocked.
So, with that suggested:
Where do the missing information from your perspective start?
To your question, which basically FWIW comes down to using a .NET 6 control in a .NET Framework process (and I figure that, because everything inside of a Type Editor (-like) Dialog needs to be shown in the context of 4.7.2-Visual Studio, but your control at that point is not): No, that's not possible. If you have a .NET 6 control, which renders content and you want that render output in a Framework process, the only way to mitigate that issue is, to render the output server-side for example to a Bitmap's DC, and then transport the bitmap back, or implement something like a rendering redirector, which would "ask" the server how to render the respective parts inside of a Framework process.
Where do the missing information from your perspective start?
I started working with your sample code several months ago, I even submitted a Pull request for a bug, but it seems to have been overlooked. Nonetheless, that is not my main concern. I am currently unable to locate a sample code that addresses my specific needs. Have you made any improvements to the sample code that I may have missed?
Thank you.