WinForms designer does not work after migrating C++/CLI (managed) from net48 to net(core)70

[chacha21]

Environment

Windows 10

.NET version

4.8, and >=7.0

Did this work in a previous version of Visual Studio and/or previous .NET release?

No response

Issue description

I try to migrate some C++/CLI (mixed/managed) projects from .net4.8 to net70

The problem is not the migration (I succeeded, it builds and run), the problem is the winforms designer.

Once my project is converted to net70, the winforms designer fails to load "Cannot load base class System.Windows.Forms.Form". Otherwise it builds and runs properly.

Steps to reproduce

https://chachatelier.fr/tmp/TestFromNetToNetCore.zip

Instructions :

• open the "TestFromNetToNetCore-net48-vs2022.sln" solution, build/run/open designer : it works
• open the "TestFromNetToNetCore-netcore70-vs2022.sln" solution, build/run:it works; open designer : it fails

Diagnostics

No response

[RobertvanderHulst]

This is probably caused by the fact that the new external windows forms designer only supports C# and VB.
See my ticket #10990 and #8381

[chacha21]

This is probably caused by the fact that the new external windows forms designer only supports C# and VB. See my ticket #10990 and #8381

And it's a huge regression. I don't even need a custom langage, it's C++/CLI.

However, the designer reported error states something like "cannot load <some System.* assembly>", so I am not even sure that parsing is the problem, it looks a like a mess in loading code with the compatibility layer needed for WinForms under a netcore context.

[RobertvanderHulst]

The designer calls into the project system to query for the assemblies that it references, so it knows where to look for types. Most likely the C++/CLI project system does not respond in a way that it "likes". I know that we have had to make some changes in that area.
Unfortunately none of this is properly documented. And it also does not help that the source code for these components is in a private repository, so we can't see what's happening.
We have had to use tools like DnSpy to figure out what's happening...

[merriemcgaw]

When we started the out-of-process designer we considered CLI/C++ as out of scope. We're focusing on managed languages 100% because we are now using Roslyn under the covers for our codegen. We could conceivably re-enable this scenario, but we would need some substantial customer reports/feedback that this is blocking them from proceeding. Thank you @chacha21 for reporting your scenario. I hate to say it, but we will need more to bring any languages other than VB.NET and C# into scope for the designer.

[RobertvanderHulst]

When we started the out-of-process designer we considered CLI/C++ as out of scope. We're focusing on managed languages 100% because we are now using Roslyn under the covers for our codegen. We could conceivably re-enable this scenario, but we would need some substantial customer reports/feedback that this is blocking them from proceeding. Thank you @chacha21 for reporting your scenario. I hate to say it, but we will need more to bring any languages other than VB.NET and C# into scope for the designer.

Our language X# is fully managed.
Your decision to move away from the language agnostic way that the internal designer works to just C# and VB is very disappointing.

[chacha21]

I hate to say it, but we will need more to bring any languages other than VB.NET and C# into scope for the designer.

I would like to say that I tried to report that regression several months (years!) ago. I used Visual Studio Feedback, Microsoft community forums, Q&A... but it has always been overlooked or totally misunderstood as a "code migration to netcore" problem (the code builds and runs, it's not the real issue).

Using this github issue is the first successful attempt to raise a real answer (yours).

So, considering the difficulty to report that problem, I think it is totally biased to wait for people to bring new scenarios. I can't be alone to use C++/CLI rather than C# because it's the only way to get such performance and level of integration with C and C++ libraries.

Perhaps a survey/poll linked to a Visual studio news/blog note could highlight the real gap between expectations vs effective feedback.

[edit]
I discovered recently that github was a good survey manager : opencv/opencv#25039

[chacha21]

Also, note that my initial problem could have a totally different solution than upgrading the Winforms designer.

I don't really care that the underlying file behind the designer is C++/CLI or C#. It's just a class that I can inherit in a C++/CLI context. But since C# and C++/CLI files cannot be mixed in the same C++/CLI project, I would have to create a separate C# project to add to the solution, and make the C# project an assembly dependency of the C++/CLI one.

But it is really cumbersome and a real pain to maintain or evolve as a code base, and even worse when prototyping things.

I don't think you will ever consider mixing C# and managed C++/CLI in the same project, but it is an alternative.