Winforms: Support third-party languages with .NET Core WinForms Designer

Created on 6 Jan 2020 · 8Comments · Source: dotnet/winforms

.NET Core Version: 3.1
Visual Studio 2019 16.5 Preview 1
Have you experienced this same bug with .NET Framework?: No

Problem description: Unable to use .NET Core Win Forms Designer with third-party languages

I'm not sure if this is the correct place to raise issues related to the Visual Studio .NET Core Win Forms designer, but I wanted to get some visibility into enabling support for third-party languages. Many VSIP language vendor partners spent a lot of time and effort into supporting the .NET Framework Win Form designer and at some point in the future customers that have .NET Framework Win Forms applications will want to move to .NET Core (.NET 5). It would be good if the new designer package could avoid hard-coded checks for project types which appears to be the cause of this particular issue. In the .NET Framework designer, the third-party project system can provide support for the language CodeDomProvider which doesn't appear possible with the current designer.

Actual behavior:

Issue occurs due to hard coded project type checks (for C#/VB) in get_Provider():

Microsoft.VisualStudio.WinForms.Package.dll!Microsoft.VisualStudio.Shell.Design.Serialization.CodeDom.Private.VSCodeDomDocDataAdapter.Provider.get()    Unknown
Microsoft.VisualStudio.WinForms.Package.dll!Microsoft.VisualStudio.Shell.Design.Serialization.CodeDom.Private.VSCodeDomDocDataAdapter.CompileUnit.get() Unknown
Microsoft.VisualStudio.WinForms.Package.dll!Microsoft.VisualStudio.Design.Serialization.CodeDom.VSCodeDomDesignerLoader.PerformLoad(System.ComponentModel.Design.Serialization.IDesignerSerializationManager serializationManager)  Unknown
Microsoft.VisualStudio.WinForms.Package.dll!Microsoft.VisualStudio.Design.Serialization.CodeDom.VSCodeDomDesignerLoader.DeferredLoadHandler.Microsoft.VisualStudio.TextManager.Interop.IVsTextBufferDataEvents.OnLoadCompleted(int fReload) Unknown

Expected behavior:

Support for third-party language integration by using the language supplied CodeDomProvider

VS designer enhancement

Source

sae42

👍8

Most helpful comment

Maybe more open communication would be good, not just with a few select vendors.

We're working on blog posts to help everyone who wants to create controls so that everyone knows what the current approach needs to be. We'll also be doing blog posts about which features are coming next and giving a much better roadmap for everyone to watch. Most of this should be coming up as we gear up to ship .NET 5. We do thank everyone for their patience with the designer. It turns out that much was rearchitected internally to support the out-of-process components and how those communicate with the VS process.

/cc: @OliaG as FYI.

merriemcgaw on 9 Oct 2020

👍2

All 8 comments

@KlausLoeffelmann do you foresee any issues doing this in the Core Designer? Let's copy this issue over there if we can do it on our end. @sae42 we can keep you posted in this issue. We haven't yet implemented everything in our Core Designer so it may just be a case that this isn't implemented yet.

FYI - Future Designer specific issues you can totally raise on Developer Community, or better yet using the VS Feedback tool. It sends along telemetry and diagnostic information that helps us understand what is happening in your particular case more effectively.

merriemcgaw on 23 Jan 2020

@merriemcgaw Thanks, please keep me posted on this issue! Right now, because of the hard block I don't really have much indication of any future issues - it's a pity the VS designer extension is not open source as I'd be able to fix it myself and be able to progress.

sae42 on 23 Jan 2020

I will open an issue in our designer repo and see what the thoughts of the team are, and how difficult this request might be.

merriemcgaw on 8 Feb 2020

What is happening to this issue - it affects Synergex too. So often extensibility is missing in new development in VS. Another choice is to just allow Languages like Cobol and Synergy/DBL to give you their GUIDS to hard code into the list, with other open source Microsoft projects we can do this by submitting PR's.

rodar21 on 8 Oct 2020

We're still looking into this issue, but to be fair our priority is getting the designer functionality to parity with the classic designer, and ensuring that control vendors have the tools they need to create custom controls. We'll be revisiting this once we've got the bulk of the expected functionality in place. All I can say for now is to say "stay tuned".

merriemcgaw on 9 Oct 2020

@merriemcgaw - I can understand your point of view but I expect the customers of other languages wanting to use .NET Core WInForms won't.

spgennard on 9 Oct 2020

👍1

I'm worrying a bit that usability of WinForms outside of C# isn't considered "parity with classic designer". The flexibility and extensibility of the WinForms designer was its major strong point, and I'm not seeing much communication with developers how to port the design time experience of their controls or VS extensions (which includes third party languages).

and ensuring that control vendors have the tools they need to create custom controls

Maybe more open communication would be good, not just with a few select vendors.

That said, I understand that the designer was/is lagging a lot behind the .NET Core port of WinForms, and also that the simple usage scenarios have higher priority than extensibility. It just feels lacking any mention in communication, so its totally unclear what your roadmap and goals are.