[dotnet-svcutil] Fully qualify XmlSchemaProvider to ensure correct resolution

[heatonmatthew]

Addresses issue #5792: Fully qualify the use of the XmlSchemaProvider attribute with the correct namespace so that types which belong in non-default Xml namespaces can be correctly resolved from referenced libraries and projects. Without this fix, it resolves to the renamed XmlSchemaProvider type in the forked framework, causing the applied attribute to not be located and the type incorrect not matches as it's assumed to be in the default Xml namespace for a referenced assembly. The effect is that the type is treated as non-reusable.

This is similar to @imcarolwang fix for #5638.

[heatonmatthew]

@dotnet-policy-service agree company="Transmax"

[heatonmatthew]

Note that I've extended the existing ReuseIXmlSerializableType unit test as it seemed the appropriate location. Previously that test used a pre-built binary for CommonTypes.dll that was checked into the repository. This made it difficult to either extend the existing test or write a parallel test using a similar referenced type assembly, so I substituted the pre-built binary for an equivalent CommonTypes.csproj. That enabled me to build on the previous work by adding the new type required in the unit test case.

[heatonmatthew]

Being unfamiliar with the test pipelines, I'm unsure whether the failures are known race-conditions or genuine failures. Is anyone able to offer any advice or assist? Thanks. 😄

[mconnew]

@imcarolwang, can you look at this and see if it's something that has been addressed with any of the other changes made, or pending?

[imcarolwang]

@imcarolwang, can you look at this and see if it's something that has been addressed with any of the other changes made, or pending?

Hi @mconnew, I looked into this. It's still needed; none of the other pending changes address it.

The root cause is a type-identity mismatch: a reused user type carries the real [System.Xml.Serialization.XmlSchemaProviderAttribute], but the forked serialization code looks up the attribute against its own forked copy. Since same-name/different-assembly types aren't equal for [GetCustomAttributes], the schema-provider method is never found, dotnet-svcutil falls back to a default name, and type reuse silently fails. This PR fixes it by pinning the lookup to the real BCL attribute, and I've verified that works.

It's rarely reported because it needs a narrow combination: type reuse enabled, the reused type implements [IXmlSerializable], it declares a custom name via [[XmlSchemaProvider]], and it's from an externally compiled assembly. It also went unnoticed because svcutil's own generated types use the forked attribute (so self round-trips worked), and the failure is silent — it just regenerates instead of reusing.

My original thinking was to leave this open until the FrameworkFork folder was removed, which would make the fix unnecessary. That work is turning out to be longer-term and incremental, and this code path isn't trivial to remove , so this fix fills the gap in the meantime.