Replace FileSaveDialogRCW and FileOpenDialogRCW with manual creation of COM object

[kant2002]

Currently NativeAOT does not support CoClass and have not plans for that for now. That's not direct statement, but I think it would be better fix here then add support in NativeAOT.

[weltkante]

Are these the only ones? I'd have thought WinForms uses more CoClasses but maybe I'm mistaken. It'd always be possible to call CoCreateInstance P/Invoke directly instead of letting the runtime do it if there's sufficient reason to work around this problem.

Looking at the thread you linked it starts with

The Native AOT compiler does not support COM interop today.

Is this still true? (I did not read through the whole thread)

There's definitely more COM usage in WinForms than just CoClass object creation.

[kant2002]

Is this still true? (I did not read through the whole thread)

COM support implemented, at least a lot of controls working. Some issues on NativeAOT front with marshalling, but overall Winforms + NativeAOT story looks promising.

CoClass declared in 3 places only

winforms/src/Accessibility/src/Accessibility.il

Line 284 in d46ad2e

.custom instance void [INTEROP_ASSEMBLY]System.Runtime.InteropServices.CoClassAttribute::.ctor(class [CORE_ASSEMBLY]System.Type) = ( 01 00 23 41 63 63 65 73 73 69 62 69 6C 69 74 79 // ..#Accessibility

winforms/src/System.Windows.Forms/src/System/Windows/Forms/OpenFileDialog.NativeFileOpenDialog.cs

Line 14 in d46ad2e

[CoClass(typeof(FileOpenDialogRCW))]

winforms/src/System.Windows.Forms/src/System/Windows/Forms/SaveFileDialog.NativeFileSaveDialog.cs

Line 14 in d46ad2e

[CoClass(typeof(FileSaveDialogRCW))]

Newing happens just for FileXXRCW in only 3 places. Because it's small and classes are internal change seems to be small.

[weltkante]

CoClass attribute doesn't need to be declared for a class to be a CoClass, so searching for it won't find all CoClasses used by WinForms. I'm wondering what part isn't implemented, the CoClass attribute semantic (being able to call new on an interface and get the corresponding CoClass, which IMHO is silly since you can just new the CoClass itself instead of the interface) - or the CoClass runtime functionality (the part which calls CoCreateInstance when doing new on a ComImport class)

[RussKie]

@kant2002 thank you for raising this issue, and feel free to raise more as you find those.
Windows Forms is intrinsically tied to Windows API and relies on COM in may different ways (e.g. for automation and accessibility support). I've had a chat with @AaronRobinsonMSFT, who knows about COM and interop way more than me, and the gist of the conversation boils down to the following. Using ComWrappers or manual COM interop is something the .NET team (this includes our team as well) is looking at, but the tooling is still missing to make it a viable option for the entire Windows Forms SDK.

The way things are panning out I can't see us making any strides in resolving this in .NET 6.0 timeframe, so marking it as "future" work.

[kant2002]

@RussKie I have simple ComWrappers which suite my needs, just these two pieces not working. Can this be community-led effort with some guidance from team? Technically let me create PR to show what minimal amount I want. If it take more testing and other unknown efforts from you, I understand that this may be abandoned.

[RussKie]

Absolutely! Maybe open a draft PR where you can show your proposal and we can discuss the approach. We'll try to muster the necessary experts, and guide you through the process.