You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
7006bb4 (and #7290) suppressed trimmable warnings to enable dependency flow. These warnings should be further investigated.
Suggestions from Jeremy and Vitek:
Annotate types that are serialized into resx. Introduce a build-time/design-time tool that that parses resx and generates list of types that should be preserved when trimming is on. In runtime ensure that these types are referenced. That might not be sufficient for report designer/winres.exe type of an application, where a resx file is loaded as a file, not as a .resources file which is linked in.
Do not put RequiresUnreferencedCode on the internal APIs, otherwise the developer would not be able to handle warning messages. In fact, a more useful messages would explain which types the developer should make "untrimmable" (explicitly referenced). For example, if developer uses an attribute with a string argument which is a type name, Developer should be informed that it's their responsibility to ensure that the named type is not trimmed (is statically discoverable)
Consider introducing alternative APIs that support trimming
In Com2Properties.cs file [return: DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)] could be used if an array of hardcoded types is replaced with a method that enumerated these types
That might not be sufficient for report designer/winres.exe type of an application, where a resx file is loaded as a file, not as a .resources file which is linked in.
Not all scenarios must support trimming. I think it's very reasonable to not support trimming in designer scenarios. Trimming is applied during publish - designers typically don't act on published apps (at least as far as I understand their behavior).
For example, if developer uses an attribute with a string argument which is a type name, Developer should be informed that it's their responsibility to ensure that the named type is not trimmed (is statically discoverable)
It's possible to add DynamicallyAccessedMembers attribute onto a string parameter - in that case it's understood as a type name. So the trimmer will preserve such type (and the necessary members).
7006bb4 (and #7290) suppressed trimmable warnings to enable dependency flow. These warnings should be further investigated.
Suggestions from Jeremy and Vitek:
RequiresUnreferencedCode
on the internal APIs, otherwise the developer would not be able to handle warning messages. In fact, a more useful messages would explain which types the developer should make "untrimmable" (explicitly referenced). For example, if developer uses an attribute with a string argument which is a type name, Developer should be informed that it's their responsibility to ensure that the named type is not trimmed (is statically discoverable)[return: DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)]
could be used if an array of hardcoded types is replaced with a method that enumerated these typesRelated to #4649
The text was updated successfully, but these errors were encountered: