Cannot serialize XML with nested classes - Microsoft.XmlSerializer.Generator 2.2.0

[NUnitTester]

The problems ocure while transforming a project from .NET Framework to .NET Core 3.1 with
Microsoft.XmlSerializer.Generator 2.2.0.
It seems to be a bug in the generator. There should be no reason to analyze types that are not serialzed.

The following example works fine with .NET Frameworks but fails in .NET Core.

    public class A
    {
        public enum Error
        { no = 0 }

        [XmlElement("value")] 
        public string V;
    }
    public class B
    {
        public enum Error
        { no = 0 }

        [XmlElement("value")] 
        public string V;
    }

Error Message:
There was an error reflecting type 'N.B.Error'.
Types 'N.B.Error' and 'N.A.Error' both use the XML type name, 'Error', from namespace ''. Use XML attributes to specify a unique XML name and/or namespace for the type.

It seems not to be neccessary but it does not help anything:

    public class A
    {
        [XmlType("Error", Namespace = "A")]
        public enum Error
        { no = 0 }

        [XmlElement("value")] 
        public string V;
    }
    public class B
    {
        [XmlType("Error", Namespace = "B")]
        public enum Error
        { no = 0 }

        [XmlElement("value")] 
        public string V;
    }

Error Message:
The top XML element 'Error' from namespace '' references distinct types N.A.Error and N.B.Error. Use XML attributes to specify another XML name or namespace for the element or types.

There is no way out ... I found nothing.
Please solve the problem urgent.

[HongGit]

@NUnitTester this is a known issue. However, the fix quite complex, will need to impact the design.

At the moment, could you please place these classes in separate assemblies and generate two separate serialization assemblies?

[NUnitTester]

Thanks for our idea.
Sorry, but using different assemblies means very much work for me, because it is not so simple as in the example. There are many classes, some of them very large or nested. I think the dependancies beetween them are quite complicated.

I have had a look on that issue and have started debugging. The Problem I found was a dictionary with a string as key. The key is the name of the class, but if the string will be the fullname with namespaces, it will work. I didn't go in deep, but this seems not be very difficulty.

By the way, there are no tests with namespaces?

So it is urgent for me.

[MatthiasPlayground]

I won't say that is is correct to put it to WCF because serialisation can be done without WCF in many usecases.
It is normal for larger hierarchies to have same named types in different locations. This is for me a must and therefor namespaces are the solution to solve such a problem.
Splitting in more assemblies is as mentioned not always possible.
Of course it is an design problem what must be solved. The name of a type is not the key, the key is the namespace together with the type. What about using namespace1.namespace2.typename as key? Sounds easy and would solve the problem. Seems to me not a big change, or why is it?

I feel that that is an big error not to handle namespaces because it is part of XML spec.
Could you please give a outlook when it will be solved.

[danielo-unity3d]

Hi. Uh, I have hit this issue (using dotnet 8 on Linux), but it annoyed me enough that I tried to debug it.
I modified my schema to add Xml namespaces to every class, and found that the XmlReflectionImporter, used by the SGen program, apparently fails to pickup, or consider, these namespaces when constructing the typemap here.
Changing the code to this instead apparently fixes the problem (although I don't know to what extent yet):

string? typeNs = null;
if (a.XmlType != null && a.XmlType.Namespace != null)
    typeNs = a.XmlType.Namespace;
root ??= a.XmlRoot;
string ns = typeNs ?? root?.Namespace ?? defaultNamespace ?? _defaultNs;

Can anyone help? (I mean, it will take me a while to confirm this, and get to the point I could assemble a PR)

[MatthiasPlayground]

could be simplified to

root ??= a.XmlRoot;
string ns = a.XmlType?.Namespace ?? root?.Namespace ?? defaultNamespace ?? _defaultNs;

[cjbush]

@HongGit @danielo-unity3d Any updates on this? It's a huge problem for us as well and simply splitting the schema across multiple serialization assemblies isn't a realistic workaround for anything more complex than a trivial example.

[thomasrea0113]

Agreed, the proposed workaround is not viable for us either. I have 8000 schemas that I do not have direct control over. It would be an org-wide restructure to get this cleaned up

[NUnitTester]

@HongGit : What must happen that this issue will be solved?
It is fact that Microsoft.XmlSerializer.Generator does not fullfill the XML spec.
As @danielo-unity3d has shown the problem seems to be easy to solve.