0

If I have a Windows service running a NET.TCP WCF endpoint and one of it's Operation Contracts returns a MyData object. How will this object be represented on the client? Will it only have fields? Will it include it's properties and methods? What about static methods? Etc.

Example:

The service contract specify a GetUser() method that returns a User object. User has a firstName field and a lastName field. It also has a FullName property that returns the firstName concatenated with the lastName. It has a method called Match(string name) that takes a name and returns a percentage using some secret algorithm that tells you how much User is love compatible with a person of that name. Finally, it has a static field PerfectMatchCount that gets incremented every time a Match gets 100%.

The User class is defined on the Server, but is returned by the GetUser() operation contract of the WCF service. When I receive the User object on the client end, will I be able to use all of it's fields, properties, methods and static fields/methods? Is there any plumbing that I need to do if I want to be able to use all of this class features, or is this limitations of WCF and I'm restricted to only a subset of that class features (which one)?

Thank You

Didier A.
  • 4,609
  • 2
  • 43
  • 45
  • 1
    I think this will help http://stackoverflow.com/questions/3734160/adding-methods-to-datacontract-objects-for-wcf – kostas ch. Jun 12 '13 at 19:11
  • @kostasch. That clarified things a lot. It was my intuition that the serialization process only serializes fields and default properties, nothing more. What I'm not sure is if the WSDL used for the auto generation of the client service would bring over anything more from the class. Now I'm starting to think that it does not. – Didier A. Jun 13 '13 at 18:11

1 Answers1

2

You can use the exact same assemblies on both the client and server in order to have the full set of class functionality in both. If you want to do this, put all the data contracts and operation contracts into a standalone assembly (dll) and reference that assembly from both the client and server projects. Don't add a Service Reference in the client project. Instead, build up your WCF channels manually.

Michael Gunter
  • 12,528
  • 1
  • 24
  • 58
  • 1
    One thing of note: with silverlight, you will not be able to share the *exact* dll. Instead, you will have to link the code files from the wcf service project into a silverlight project. – Josh C. Jun 12 '13 at 19:15
  • So I assume that the auto generated proxy class does not bring over anything else but the fields and default properties of the class? – Didier A. Jun 13 '13 at 18:12
  • @JoshC. I am in fact using Silverlight as my client. Manually creating the proxy to work in async and for the amount of Operation Contract that my Service uses would be extremely painful. I might try your method instead. I assume I can still generate the contract using the service reference, but tell it to reuse types in referenced assemblies, so that it uses my Linked classes from my Silverlight project for my entity classes instead? – Didier A. Jun 13 '13 at 18:17
  • @didibus that is exactly how you should do it. Again, when adding an existing item in visual studio, make sure you open the menu button and add as link. There are many tutorials on this. http://stackoverflow.com/a/1689527/918608 – Josh C. Jun 13 '13 at 19:24
  • @JoshC. Do you think a Shared Portable Library Assembly would also work? Instead of the linking? – Didier A. Jun 13 '13 at 20:22
  • @didibus It *can*. Some assemblies have been ported to Silverlight, but not all. Debugging can be tough. For instance, System.Windows.Point is different between Silverlight and the full framework. Be careful. – Josh C. Jun 13 '13 at 20:26