Will the designer always be ran out off process?

[willibrandon]

Or is the plan to one day bring the designer back into the Visual Studio process?

[RussKie]

I don't believe that'd ever happen. Consider, VS is running on net472 and your project targets .NET - the designer has to run out-of-proc. Now, it's plausible to consider that one day VS may run on .NET, then .NET Framework projects have to run out-of-proc. Not to mention the present scenario - VS is a 64-bit process, and your .NET Framework project requires 32-bit support...
And once you have both version of the designer running out-of-proc, then there's little to no incentive bring those in-proc.

[willibrandon]

That makes sense, thanks for the insight. This really helps me understand some of the challenges you have had with the designer and is very interesting.

[RussKie]

You may find some of these blogs insightful:

• https://devblogs.microsoft.com/dotnet/state-of-the-windows-forms-designer-for-net-applications/
• https://devblogs.microsoft.com/dotnet/custom-controls-for-winforms-out-of-process-designer/

[willibrandon]

Very much so. Of course now I have some ideas and will keep playing with this to see if I can come up with anything useful.

[willibrandon]

I've never built a custom control before, and don't have experience with the designer. But if I can, I'll try to get up to speed and implement something similar to what is described in IDragSourceHelper::InitializeFromWindow Remarks.

The DI_GETDRAGIMAGE message allows you to source a drag image from a custom control. It is defined in Shlobj.h and must be registered with RegisterWindowMessage. When the window specified by hwnd receives the DI_GETDRAGIMAGE message, the lParam value holds a pointer to an SHDRAGIMAGE structure. The handler should fill the structure with the drag image bitmap information.