Disclaimer The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.
Our friends at Microsoft may have slipped one in on us. After installing the 3.5 Framework Service Pack 1, it appears that you no longer need the [DataContract] or [DataMember] attributes on your DataContracts and DataMembers. I'm not sure what the motivation was for this "enhancement", but it caused some trouble for me the other day.
For this example I will be using the base project VS2008 gives you when you create a new WCF Service Library. I am simply adding a NestedType to the CompositeType given in the base project.
Before installing SP1, having code as it appears below would cause an error during Metadata Exchange that reads something like "Metadata contains a reference that cannot be resolved". Notice that CompositeType's NestedObject is marked as [DataMember] and also notice that the NestedType class is not marked as [DataContract] and has no [DataMember] attributes. Adding [DataContract] on NestedType and [DataMember] on IsVisible will clear this error and everything will work as expected.
24 [DataContract]
25 public class CompositeType
26 {
27 bool boolValue = true;
28 string stringValue = "Hello ";
29 NestedType nestedObject = new NestedType();
30
31 [DataMember]
32 public bool BoolValue
33 {
34 get { return boolValue; }
35 set { boolValue = value; }
36 }
37
38 [DataMember]
39 public string StringValue
40 {
41 get { return stringValue; }
42 set { stringValue = value; }
43 }
44
45 [DataMember]
46 public NestedType NestedObject
47 {
48 get { return nestedObject; }
49 set { nestedObject = value; }
50 }
51 }
52
53 public class NestedType
54 {
55 bool isVisible = false;
56
57 public bool IsVisible
58 {
59 get { return isVisible; }
60 set { isVisible = value; }
61 }
62 }
The same code in use after SP1 will not cause this error. WCF will interpret from CompositeType's [DataContract] attribute and NestedObject's [DataMember] attribute that you meant to put [DataContract] on NestedType. So what's the big deal, right? WCF is doing me a solid by guessing at what I meant to do. To me, this violates the repeated opt-in theme present in WCF. For every other important decision, the developer must write code to opt-in to a feature. For example, TransactionFlow defaults to false so we don't use the client's incoming transaction with explicitly writing code that says to do so.
This is clearly not on the same level as TransactionFlow. But why does it assume something about my objects? Why does it assume that every member of my object should be a DataMember?
I noticed this new "feature" when troubleshooting some code that had different namespace names specified in the DataContract attribute. Since the NestedType did not have a [DataContract] attribute, the namespace was using the original namespace name. The equivalent of CompositeType came through correctly, but the NestedObject had no value.
Remember Me
a@href@title, strike