NativeTypes namespacing question

We noticed that if we have two types of the identical name, under different namespaces, when being used in yet a 3rd namespace, the exact type specified is lost, and only the based class name remains. Which results in you can have the “wrong” type on the other end, or ambiguous type errors. Is there any reason why NativeTypes couldn’t have a VerboseTypes option which would force full type names(e.g. System.Int32, A.AThing)?

Our resolution was to just refactor the code as we really shouldn’t have been sharing between those items to begin with, but was still interested if it might be beneficial to support such structures.

Sample below:

namespace A
{
    public class AThing
    {
        public int Value { get; set; }
    }
}

namespace A2
{
    public class RequestAThing : IReturn<A2.AThing>
    { 
    }

    public class AThing
    {
        public string Value { get; set; }
    }
}

namespace B
{
    public class RequestUsingAAThing : IReturn<A.AThing>
    { 
       
    }
}

NativeTypes C# output is:

using A2;
using B;

namespace A
{

    public partial class AThing
    {
        public virtual string Value { get; set; }
    }
}

namespace A2
{

    public partial class AThing
    {
        public virtual string Value { get; set; }
    }

    public partial class RequestAThing
        : IReturn<AThing>
    {
    }
}

namespace B
{

    public partial class RequestUsingAAThing
        : IReturn<AThing>
    {
    }
}

Most Native Types Languages require each DTO to be uniquely named since most languages don’t have namespaces with equivalent semantics to C#/.NET (neither does F#). So to maximize the accessibility of your Services each DTO should be uniquely named (it also causes issues in other ServiceStack features requiring unique names).

Relying on language-specific features like namespaces works against web services interoperability, makes the generated DTO’s more verbose, uglier and harder to read and is contra to the GlobalNamespace feature which strips all DTO namespaces under a single namespace - hiding the complexity of the server namespaces by presenting them under a single namespace view, making it easier to integrate into Client Applications.

1 Like