Epic - Make WinForms trim compatible

[agocke]

The TrimTest project tracks a simple WinForms application for trimming purposes. This project generates 2535 trim warnings -
Default_Trimmed_Warnings.txt.

Below issues track the work related to getting the warnings addressed.

Linked to this epic

• Interop related work to enable WinForms trimming #10797
• [Umbrella-Item] Make WinForms DataBinding Apps trimmable #10741
• Microsoft.WindowsDesktop.App.Runtime pack should respect WinForms-Wpf profiles sdk#37088
• Remove trim warnings from ComponentModel APIs that take Type as a parameter runtime#97841
• DesignerAttribute/EditorAttribute size implications runtime#92043
• Remove RequiresUnreferencedCode from DefaultValueAttribute runtime#97842
• Reflection API calls need type annotation #10807
• Make APIs that take object as a parameter trim safe #10810
• Make serialization trim safe #10812
• Add a new feature switch for WinForms trimming #10813
• Size of WinForms with PublishAot #9911
• [Tracking] Make TrimTest project trimmable #10798
• Enable IL2057;IL2062;IL2096 trimmable warnings #7464

[RussKie]

From an offline chat with @agocke:

(These) warnings effectively represent reflection that the toolchain can't figure out. In most cases the warning is probably about a use of a particular reflection method and will tell you that the System.Type you're operating on isn't marked with the same requirements as the reflection method requires. After finding the source of the System.Type you have two options:

1. The type is statically known, like typeof or even a string literal with the full name
2. The type is retrieved dynamically, like from an arbitrary object.GetType() or from a name from the user

In case (1), this is likely just an annotation problem. You need to use the DynamicallyAccessedMembers attribute to walk back through the code path, and mark the type as requiring the specific capabilities. When you get back to the original typeof call or whatever, the toolchain will be able to figure out what it needs to preserve on the type.

In case (2), this is fundamentally not linker safe. There's no guarantee that the thing you're reflecting against won't be trimmed, and the member won't be gone at runtime. For that it's usually recommended that you use RequiresUnreferencedCodeAttribute on the method. It silences the method warnings, but produces a warning for anyone calling that method. You can keep doing this until you bubble it up to the public APIs, where users will get a warning that the method is not linker safe.

Useful docs:

• https://github.com/mono/linker/blob/main/docs/design/reflection-flow.md#linker-friendly-reflection
• https://devblogs.microsoft.com/dotnet/app-trimming-in-net-5/

[weltkante]

I find no mention of COM interop in the links, the warnings about COM interop not being supported are worrying (IL2050: xxx declares a parameter with COM marshalling. Correctness of COM interop cannot be guaranteed after trimming. Interfaces and interface members might be removed.) since this is fundamental functionality to communicate with Windows (WinForms without clipboard, drag'n'drop, RichEdit, accessibility etc. would not be the same)

Furthermore the text mentions trimming of COM interfaces yet only reports P/Invoke signatures. That has me worried that ComImport is not recognized by the linker and also gets broken (otherwise the comment about trimming interface members makes not much sense). Trimming members of ComImport interfaces is definitiely not allowed (changes method order which is fatal for IUnknown based interfaces) and I'd expect this to be easily recognizable (just check the attribute) so I'm confused what the warning means in the first place.

I really hope these are just false positives and COM interop is supported, or at least can be supported by custom annotations, otherwise I don't think WinForms can be made compatible.

[merriemcgaw]

Adding this to our dotnet/planning/issues/27 theme