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
Notice how the code first creates an <example> element and then overwrites both tags with the right name. That's not technically wrong, but it's certainly a confusing way to create the tree.
Ideally, RoslynQuoter should use a specific factory method, when one is available (in this case, XmlSummaryElement). Though always using the generic XmlElement method would be fine too.
The text was updated successfully, but these errors were encountered:
Unfortunately the algorithm breaks down when there's more than one way to create the given tree. It works so well in general because usually there's only a single method that can create a node of the desired type, so there's no ambiguity.
However Xml factory methods were added later, and they have a few convenience methods, so the algorithm just chooses the first one that works, and that explains the results above.
We'd need some heuristics to fine tune this behavior and provide hints to the algorithm on a case-by-case basis.
Consider a member with XML documentation comment:
The relevant section of code generated for the XML comment is:
Notice how the code first creates an
<example>
element and then overwrites both tags with the right name. That's not technically wrong, but it's certainly a confusing way to create the tree.Ideally, RoslynQuoter should use a specific factory method, when one is available (in this case,
XmlSummaryElement
). Though always using the genericXmlElement
method would be fine too.The text was updated successfully, but these errors were encountered: