Collections are simplified when they go over the wire. You can specify the collection-type via the IDE and command-line (svcutil /collectionType
), but it will apply to all collections on the API. I think you should just accept it, and handle the mismatch through code. Ultimately, on the wire, collections are just xml (over the standard bindings, at least) - something like:
<items>
<item ...>...</item>
<item ...>...</item>
<item ...>...</item>
</items>
- hence why it can't tell (from the schema) between an array (T[]
), a List<T>
, a HashSet<T>
, and a MyFunkyCollection<T>
.
Note that if you use assembly sharing (i.e. the same service contract assembly is at the client and server) then this won't happen - but that defeats the intent of SOA/mex. But is is an approach used quite a lot - hence the IDE supports it directly, and command-line via a switch (svcutil /reference
).
For the IDE supporting it... if you write the service contract and data contract in a class library (dll), and then add an assembly reference (i.e. a dll reference or a project reference) to this library from the two projects (the server project and the client project). Now add a service reference from the client project to the server endpoint (the .svc). If you are using VS2008, it will automatically check local references for types and use those in place of proxy generation - meaning: your client code uses the IwcfServerSync
from the class library, which already knows whether to use HashSet<T>
etc.