Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolve ILLink warnings in System.ComponentModel.TypeConverter (Round 2) #49467

Merged
merged 5 commits into from
Mar 15, 2021

Conversation

eerhardt
Copy link
Member

Contributes to #45623

@ghost
Copy link

ghost commented Mar 11, 2021

Tagging subscribers to this area: @safern
See info in area-owners.md if you want to be subscribed.

Issue Details

Contributes to #45623

Author: eerhardt
Assignees: -
Labels:

area-System.ComponentModel

Milestone: -

@eerhardt eerhardt added the linkable-framework Issues associated with delivering a linker friendly framework label Mar 11, 2021
@dotnet-issue-labeler
Copy link

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

public string DesignerBaseTypeName { get; }

/// <summary>
/// Gets the name of the designer type associated with this designer attribute.
/// </summary>
[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we want this actually. Are the designers ever used at runtime?
The problem is that this will basically force include the designer types and some code from them into apps - but they will never be used (since they're designers, those should not run at runtime).
Also - the only method which accesses this TypeDescriptor.CreateDesigner is already marked with RUC - and I think we should not allow calling it on a trimmed app.

Technically the annotation is correct, I'm questioning if it's the right thing to do for size.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the only method which accesses this TypeDescriptor.CreateDesigner is already marked with RUC - and I think we should not allow calling it on a trimmed app.

Just because a method is marked with RUC doesn't mean it can't be called in a trimmed app.

Maybe if this becomes a size issue for WinForms, they can strip out DesignerAttribute instances by default - similar to how we strip out some attributes in Blazor WASM that aren't needed at runtime.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a good point that a better size solution is to strip out the attribute as a whole.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These attributes can be and are used at runtime by PropertyGrid control, and can be used by custom designers (e.g. a report viewer)

public ComNativeDescriptorProxy()
{
Assembly assembly = Assembly.Load("System.Windows.Forms");
Type realComNativeDescriptor = assembly.GetType("System.Windows.Forms.ComponentModel.Com2Interop.ComNativeDescriptor", throwOnError: true);
Type realComNativeDescriptor = Type.GetType("System.Windows.Forms.ComponentModel.Com2Interop.ComNativeDescriptor, System.Windows.Forms", throwOnError: true);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI - @AaronRobinsonMSFT. I changed this pattern given the discussion at dotnet/linker#1884 (comment).

Let me know if you have feedback on this change. And how I can test it to make sure I didn't break the scenario.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks fine to me. Adding @JeremyKuhne, @RussKie, and @merriemcgaw for WinForms impact.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be ok? I've never fully walked through this though. :(

@eerhardt eerhardt force-pushed the TypeConverterILLinkWarningsRound2 branch from addd814 to 0562916 Compare March 12, 2021 23:42
Copy link
Member

@joperezr joperezr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes LGTM.

@@ -485,7 +485,7 @@ internal PropertyDescriptorCollection GetProperties()
/// then a global Type.GetType is performed.
/// </summary>
[UnconditionalSuppressMessage("ReflectionAnalysis", "IL2026:RequiresUnreferencedCode",
Justification = "typeName is annotated with DynamicallyAccessedMembers, which will preserve the type.")]
Justification = "Calling _type.Assembly.GetType on a non-assembly qualified type will still work. See https://github.com/mono/linker/issues/1895")]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not 100% true, but I think it's probably good enough for now. Once we solver the linker issue referred here, we'll see if this needs some tweaking or not.

@eerhardt
Copy link
Member Author

runtime failures are #49569

@eerhardt eerhardt merged commit ddff65b into dotnet:main Mar 15, 2021
@eerhardt eerhardt deleted the TypeConverterILLinkWarningsRound2 branch March 15, 2021 20:45
@ghost ghost locked as resolved and limited conversation to collaborators Apr 16, 2021
@karelz karelz added this to the 6.0.0 milestone May 20, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.ComponentModel linkable-framework Issues associated with delivering a linker friendly framework
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants