SDK-Read-this-first. Believe me, it's important! 😸
KlausLoeffelmann opened this issue · 4 comments
This issue is a permanent discussion issue pinned to the repo to draw the attention to a couple of things which are important, when you start porting your Control Designers from (currently) .NET Framework to .NET.
The following is a 3-minutes read - pretty, pretty, please: read it!
Let's start with some important terminology - a quick clarification on that term ".NET":
- When we talk about "just" .NET, we mean in the context of WinForms .NET Core usually 3.1, 5.0, 6.0, 7.0, 8.0 and future versions in that line.
- .NET Framework on the other hand (we also call that NETFX often internally) are the versions in the line ending with 4.8.1, and there won't be any further major versions nor any new features in that line of .NET Frameworks.
Mirror, Mirror on the Wall: .NET Core and .NET Framework's Uncommon Commonalities
So, with that said, there is a BIG breaking change in the WinForms Designer. And that change is due to the fact, that there is no feasible way to "combine" a .NET (for example version 6) WinForms App Version Target (we call this short TFM for Target Framework Moniker) and a Framework TFM in one process. Which means: A .NET 6 WinForms App need to instantiate a Form, a Button, a Label during Design Time. So, it needs a .NET 6 process to run. But there is none. Why? Well, Visual Studio is targeting .NET Framework 4.7.2. And that's the reason, we need to take the actual Core WinForms Designer part out of the Visual Studio Process and place it in an additional new process, which runs targeting the same .NET version which your actual App is targeting.
The same, btw, is true for a .NET Framework App, which can only run in .NET Framework 32-Bit. In Visual Studio 2022, we don't have such a process anymore. Yes, VS is still a Framework process, but it's not 32-Bit. It's 64-Bit. So, again, we cannot combine those different requirements in one process, which is why we need again to have another process and make the two processes talk to each other.
This has in some WinForms Control Library scenarios MAJOR implications on the architecture of such Control Designers. And that's why you need to read the following blog post,
Yes, this one is the link to the blog post...
to get a full picture, before you get started with the samples in this repo and the SDK for authoring Control Designers for the WinForms Out-Of-Process Designers.
An additional, general ask:
If you have general follow-up questions, let's discuss them here.
If you have specific technical questions, please create a new issue.
And with all that said one last remark about another terminology issue:
This is the reason, we are talking about the
- WinForms Out-Of-Process .NET Designer, the
- WinForms Out-Of-Process .NET Framework Designer, and just the
- (In-Proc, classic) WinForms Framework Designer.
Hi @KlausLoeffelmann ,
What about root designers?
Is there any ETA for next version of Microsoft.WinForms.Designer.SDK ? beta version perhaps?
Currently it seems that this feature is not yet supported: VS 17.8.0 Preview 4.0 + Microsoft.WinForms.Designer.SDK --version 1.6.0
Aiming for 17.9.
First beta somewhat likely Preview 1, more likely Preview 2, depending how quick we can solve a few depending issues.
The reason is, that we needed to refactor quite a bit of the internal Designer infrastructure first, to make some additional and required APIs public. And we need to be very mindful with that, to not break the existing WinForms Designer. When we're sure that that works, we can release the API in beta. Of course, the WinForms Designer must be released first for the API to work, so the Root Designer will not work with easlier versions of the WinForms Out-Of-Proc Designer.
Hi, @KlausLoeffelmann,
Is there a change that the client-server way (described in the Custom Controls for WinForm’s Out-Of-Process Designer blog post) will be changed in the near future and will no longer needed? Let's say the VS will support UITypeEditor in a simpler way for .NET WinForms Designer as well as previously.
If so, we can wait and just switch to old project on NETFX to update the designer. If not, the we will be forced to do this slightly confusing way.