Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

MichalStrehovsky
Copy link
Member

@MichalStrehovsky MichalStrehovsky commented Aug 2, 2023

Condition="'$(ThreadPoolMaxThreads)' != ''"
Value="$(ThreadPoolMaxThreads)" />

<RuntimeHostConfigurationOption Include="System.Xml.XmlResolver.IsNetworkingEnabledByDefault"
Copy link
Member

@eiriktsarpalis eiriktsarpalis Aug 2, 2023

Choose a reason for hiding this comment

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

The STJ property controlling the System.Text.Json.JsonSerializer.IsReflectionEnabledByDefault swich was named JsonSerializerIsReflectionEnabledByDefault. Echoing that naming convention, shouldn't this also be named XmlResolverIsNetworkingEnabledByDefault?

Typically this needs to go through API review but maybe we can fast-track this. cc @eerhardt @bartonjs @terrajobst

Copy link
Member Author

@MichalStrehovsky MichalStrehovsky Aug 2, 2023

Choose a reason for hiding this comment

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

We've not done API review on these or they would be consistent.

The XXXSupport is a prevalent theme for things that disable support for something

DebuggerSupport, EventSourceSupport, HttpActivityPropagationSupport, MetadataUpdaterSupport, NullabilityInfoContextSupport, CustomResourceTypesSupport, DynamicCodeSupport, BuiltInComInteropSupport,...

(The Json one is the odd one out)

Copy link
Member

Choose a reason for hiding this comment

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

One difference between the existing XXXSupoort flags and the JsonSerializerIsReflectionEnabledByDefault flag is that the XXXSupport flags completely remove the ability for doing XXX. Where the JsonSerializer is still capable of doing reflection, it just won’t do it by default when the flag is set. Thus the verbose naming (it’s trying to be correct/precise).

I don’t know exactly which case the new XML flag falls into, but if the XmlResolver can still use networking even if the flag is set, I wouldn’t name it XXXSupport. Because it can still do it, even though the flag is set.

Copy link
Member Author

Choose a reason for hiding this comment

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

@jozkee @krwq do you know which side IsNetworkingEnabledByDefault is on so we can finalize the name?

Copy link
Member

@eiriktsarpalis eiriktsarpalis Aug 4, 2023

Choose a reason for hiding this comment

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

I'm not familiar with the code, but looking at this change suggests that it falls on the same boat as the STJ switch. It picks the XmlUrlResolver implementation if the switch is turned on, which is a public class. The behavior of XmlUrlResolver itself doesn't seem to be affected by the feature switch.

The choice of name for the feature switch also suggests similarity with the STJ one, so we might want to emulate naming convention for the property as well.

Copy link
Member Author

Choose a reason for hiding this comment

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

@eiriktsarpalis @eerhardt if this updated name looks good, could you please merge? I'm off work through end of August. It would be nice to have this in 8.0.

Copy link
Member

Choose a reason for hiding this comment

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

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add an msbuild property that toggles the XmlResolver.IsNetworkingEnabledByDefault feature switch
3 participants