Colliding types in add service stack reference

Clients Add ServiceStack Reference
1

ServiceStackUniversalAssetServiceReference.dtos.cs(174,29,174,37): error CS0104: ‘TimeZone’ is an ambiguous reference between ‘System.TimeZone’ and ‘UniversalAssetService.ServiceModel.Types.TimeZone’

hi … How can I get rid of this problem ? I didn’t find an option to workaround this problem (such as havng types emitteted with full namespace.

thank you
enrico sabbadin

2

Rename your TimeZone DTO to something else which doesn’t conflict with built-in System types. The generated DTO’s don’t include full namespaces as they’re emitted for clarity/readability.

3

Hi, I suggest to add an option to emit full namespaces , I’m currently having a situations where I cannot rename the type, since they are defined in a DLL …

best regards
enrico

4

In that case don’t use Add ServiceStack Reference which requires unique DTO names and share your Service Model (aka DTO) .dll’s instead.

Note: the place to suggest features is on ServiceStack’s UserVoice.

5

I have an issue similar to this due to the servicestack reference not including qualified type names. I’ve defined serialization (POCO) classes for passing data where a property is defined using a type that doesn’t get properly defined in the generated reference code. For example; a property of type System.Data.DbType. This prevents the generated DTO class from compiling as the type definition, DbType, cannot be resolved.

To get my projects to build I’ve either had to change the property types to something generic like ‘string’ or to abandon the generated DTO and reference the POCOs through a shared library. Neither of these solutions are good.

Regards,

Bob

6

If you want to export BCL Enums you can try exporting the types, e.g:

var nativeTypes = this.GetPlugin<NativeTypesFeature>();
nativeTypes.MetadataTypesConfig.ExportTypes.Add(typeof(DbType));

But fully qualified names are terrible for DTO’s, causes namespaces to break serialization and prohibits your services from working in other languages inhibiting interoperability - your external Service Contracts shouldn’t be relying on them, if they do you’re limited to .NET and sharing .dlls.

7

Good point about interoperability. Thanks.