Adding WCF service reference adds DataContract types too

I've used Visual Studio's Add Service Reference feature to add a service (actually it is a workflow service, created in WF4 RC1, but I don't think this makes any difference), and it also added the DataContracts that the service uses. At first this seemed fine, because All I've had in the DataContracts was simply properties, with no implementations. But now I've added code in the constructor of one data contracts that initializes creates an instance of one of the properties that exposes a list of other DCs, and when I've updated the service reference via VS (2010 RC1), the implementation was not updated.

What should I do? Should I use my DCs instead of the ones created by VS or should I use the ones VS created? I've noticed that the properties in the VS-generated DCs contain some additional logic for checking equality in the setters and they also implement some interfaces too (like IExtensibleDataObject and INotifyPropertyChanged) which might get handy I guess in the future (I'm not knowledgeable at 开发者_Python百科WCF).

Thank you for your time folks, Avi

Yes, that is the way it works - and that's really the only way it can work if you think about it, when you have a separate, autonomous service.

If you control both ends of the wire, e.g. you write both the service and the client, you can of course do a few more things:

• you can put all your service and data contracts into a separate assembly, MyContracts, and then add a reference to that assembly both on the service as well as the client side

• when you do that, Visual Studio will not re-create those types that it finds in that referenced assembly, but it will just use those

But you need to be extremely careful: Data Contract should only ever contain data - never any behavior! So be extra careful not to put any behavior-based stuff into your DataContracts. The message going between client and service in WCF is a pure text-based serialized message - you cannot convey any code between the two, really - keep that in mind!

marc_s, How can I create this separate assembly "MyContracts" if my client is in Silverlight? I certainly cannot create this assembly as a .NET one, because in such case it is not possible to reference it from my SL project. Yes, I can create this assembly as a "SL Class Library" and even reference it from my WCF project, but then I cannot perform "Update service reference" in Studio! I get error "Could not load file or assembly 'System.Runtime.Serialization, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' or one of its dependencies. The system cannot find the file specified". Note that v.2.0.5.0 is the SILVERLIGHT version of this DLL, not the .NET one! Seems it needs this DLL to understand the DataContract/DataMember attributes present in the "MyContracts" assembly. If I put this DLL on the server (hosting my WCF services) - the problem goes away, but instead another problem appears with those services that do not use "MyContracts" assembly and contain DataContracts right inside themselves: "Type '...' cannot be serialized. Consider marking it with the DataContractAttribute attribute, and marking all of its members you want serialized with the DataMemberAttribute attribute.  See the Microsoft .NET Framework documentation for other supported types". Seems that it can't understand which System.Runtime.Serialization.dll to use - SL or .NET one. Any ideas?!