How to use ImageEditor, BitmapEditor, and MetafileEditor in the imagecollectioneditor using Client-Server Approach for .NETCore

[NagarajManimaran]

Environment

Visual Studio professional 2022 - version 17.13.0

.NET version

.NET 8

Microsoft.Winforms.Designer.SDK version - 1.6.0

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

No

Issue description

Previously, you mentioned using the client-server approach to make the CollectionEditor work in .NET Core. I implemented this approach, and the CollectionEditor is working properly.

Previous_link : #10549

However, in our case, the ImageEditor, BitmapEditor, and MetafileEditor are used in the ImageCollectionEditor. In .NET Framework, the CollectionEditor works without any errors. But when I use ImageEditor, BitmapEditor, and MetafileEditor in our ImageCollectionEditor with the client-server approach in netcore, an error occurs because these editors are not available in the Microsoft.WinForms.Designer.SDK package.

Is there a way to access ImageEditor, BitmapEditor, and MetafileEditor for my imageCollectionEditor? If not, is there an alternative approach to implement these editors?

I have attached a simple Client-Server approach sample. Kindly provide me suggestions to resolve this issue.

sample_link : ImageCollection-Net9.zip

Steps to reproduce

Steps to reproduce
1.Open the sample.

Observed Behavior
ImageEditor, BitmapEditor, and MetafileEditor is not available in the Microsoft.WinForms.Designer.SDK package.

Expected Behavior
Need to use the ImageEditor, BitmapEditor, and MetafileEditor in the Server Library.

Diagnostics

[KlausLoeffelmann]

are not available in the Microsoft.WinForms.Designer.SDK package.

Well, they are not only not available in the SDK package, they are not available full-stop because they simple do not exist.

See, we have tried to streamline the port of everything tight to the Control Designers and made sure we reuse, what's possible, so when we need to work on a NetFX Dialog, then this would automatically also been picked up by the Out-Of-Process Designers for once, and then, porting the UI to OOP means also, we need to provide server-side ViewModels, DTOs for data exchange via the protocol libraries, and what have you.

Now. Since at points the difference from what the UI needs to support on the client (Visual Studio) side is too different in NETFX and .NET, we cannot reuse what is in NETFX, and at that point, we needed to do that work. The DataBinding experience is the best example, where this was inevitable to do.

Now, this area is a little bit delicate altogether, since technically the Designers for NETFX are in the NETFX libraries alright. But from a Microsoft internal domain-specification perspective, they belong to Visual Studio. You see this, whenever you access the reference source. If you can only see the stubs, that's then the case.

So, that is also the reason that we have the base classes public but most of the more "complex" Control Designers UI-depended functionality in NETFX was internal all along. And that was not, to say "uhh, that's ours you cannot have it" - it's more complicated with that, and it has to do with support duties, with security, with laws for A11y ... you name it. A runtime here has way different demands than a product. And - and here is where my expertise stops, and I am just trying to reasonably assuming, so Disclaimer: what I am about to say is an explanation attempt, I am not qualified to make binding statements of course! - if a lawmaker came to us and said: This part of Visual Studio is not A11Y compliant, we would have a hard time and say, "Pfff, that's not part of VS, that's the runtime...".

Which means, ultimately, if you are surfacing something in your App, which could be seen as part of Visual Studio, it remains "our" responsibility. The moment you inherit it and redesign the Dialog, it can no longer be part of Visual Studio but becomes "your" Editor (assumingly for a Custom Control at Design Time, or for an UI you want to use in the context of the Property Browser at runtime).

OK - so much for the principal situation, as I understand it. Now, what can we do?
It really depends. You could inherit the Dialog on the client side and modify it alright. But that would not help you in that case. Because now, there is no longer a compatibility between NETFX and .NET. The functionality on .NET-side requires now, which we also had to do with so many dialogs: Reimplement the logic completely and separate out Client- and Server-Side functionality.

I say all this with a bit of reservation, because we have one really genius architect, which I would like to check with. And maybe he will shortly roll his eyes, smile and say: Go patch your answer, here is an alternative approach. But...it's the MVP Summit right now, and the chance, that I will come back and say "Uhhh - I got it all wrong" is, let's say < 15%.

But I will ping you IMMEDIATELY, once he or I can think of something less "modernization-intensive" for you. In fact, I have a few approaches in mind, which could drastically reduce the effort here, but that's nothing which is around the corner.

[NagarajManimaran]

@KlausLoeffelmann Thanks so much for the detailed explanation!

Just to confirm my understanding: in .NET Core, since the original ImageEditor and related designer dialogs were never ported, we need to rebuild our own custom editor using the new client-server model with ViewModels and DTOs — is that correct?

If so, could you please share:

Any sample or reference on how to implement a custom UITypeEditor (like ImageEditor) for the .NET Out-of-Process Designer?

Any guidance on integrating it with the new Microsoft.DotNet.DesignTools.* infrastructure?

Also, please do let me know if your architect colleague comes back with an alternative approach or recommendation — that would be really helpful!

[NagarajManimaran]

@KlausLoeffelmann any further updates reg this? #13178 (comment)