Multiple generated clients referencing same type : compiler error

Hello,

I got a global enum referenced by two ServiceStack Web Api.
When I add those 2 services as client auto-generated code to the same project, the compiler is firing an error: “The namespace already contains a definition for this enum”.

How can I handle this?

Thanks,
Olivier

If it’s the same Enum that’s duplicated you can use the DTO Customization Options in one of the Service References to ExcludeTypes,

Otherwise if their different Enums, change the Enum’s name that’s sent on the DTO, your Types should be unique across the entire Process boundary.

It’s the same enum … ExcludeTypes does the trick :). The downside is that you have to do this for all duplicate types and it is not very user-friendly (every end user will have to add this manually [can you set default exclude types server side ?]).

We got all public DTO in one assembly (to ease sharing internally/externally, Nuget creation, global naming) but we have multiple service stack web API exposing them (MicroService architecture). Does this architecture (multiple services but all public DTO in one assembly) fit ServiceStack?

Sure, if you have all DTOs in the same assembly, you can just share that .dll with clients instead of using Add ServiceStack Reference. Note the client development experience is greatly improved if all Request DTOs are annotated with IReturn<T> and IReturnVoid interface markers.

Thanks mythz,

I will add the ServiceStack.Interfaces dependency to the global DTO assembly and annotate request DTO with “IReturn…”.

It’s very nice that AutoQuery abstraction is in ServiceStack.Interfaces, I can put the related DTO in the same global DTO assembly.

Exclude types will do for now, Nuget / other language packages will be for later :slight_smile:

Everything that should be in DTOs will be in ServiceStack.Interfaces.dll which should be the only .dll your DTOs should ever need to reference. If they ever need a reference to any additional .dlls you have a coupling issue which should be refactored so DTOs no longer have a direct dependency on them.