Annotate System.ServiceModel.Syndication for trimming and AOT #114028
Conversation
|
Note regarding the |
|
Note regarding the |
dotnet-policy-service
bot
added
the
community-contribution
| public SyndicationElementExtension(string outerName, string outerNamespace, object dataContractExtension) | ||
| : this(outerName, outerNamespace, dataContractExtension, null) | ||
| { | ||
| } | ||
|
|
||
| [RequiresUnreferencedCode(SyndicationFeedFormatter.RequiresUnreferencedCodeWarning)] | ||
| public SyndicationElementExtension(string outerName, string outerNamespace, object dataContractExtension, XmlObjectSerializer dataContractSerializer) |
There was a problem hiding this comment.
DataContractSerializer's constructor isn't RequiresUnreferencedCode, but all of the methods on it are. This constructor just creates a DataContractSerializer without using it, so technically it doesn't need RequiresUnreferencedCode.
If you use this constructor, a bunch of other members on this class will use that DataContractSerializer. If you use the constructor taking XmlReader, they don't use any serializer and are perfectly trim-compatible.
So, I think it's better to leave the attribute on this constructor. Otherwise, all those members would need to be marked RequiresUnreferencedCode. This way, if you use the XmlReader constructor, you won't get warnings.
Does that make sense?
| @@ -109,6 +118,8 @@ public string OuterName | |||
|
|
|||
| public string OuterNamespace | |||
| { | |||
| [UnconditionalSuppressMessage("Trimming", "IL2026:RequiresUnreferencedCode", Justification = "Constructors not marked RequiresUnreferencedCode always set _outerName to a non-null value.")] | |||
| [UnconditionalSuppressMessage("AOT", "IL3050:RequiresDynamicCode", Justification = "Constructors not marked RequiresUnreferencedCode always set _outerName to a non-null value.")] | |||
| get | |||
| { | |||
| if (_outerName == null) | |||
There was a problem hiding this comment.
Since this path is statically reachable, the linker will still keep around bits of XmlSerializer and DataContractSerializer, right? Is there something easy we can do about it?
There was a problem hiding this comment.
You can split the ExtensionDataWriter nested class into a base abstract class (or interface) and a concrete implementation, and create the latter only in the trim-unsafe constructors.
Despite the closeness of this library to XML and WCF, the reflection usage in this library is nicely cordoned off and mostly limited to convenience methods. Thus, the library is largely trimming-compatible.
Fixes #113990
Contributes to #75480