Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>To add some detail to the question you ask in the comments... in the good old (3.0) days WCF/<code>DataContractSerializer</code> was pretty strict. If your type wasn't explicitly marked as a <code>[DataContract]</code> (or <code>IXmlSerializable</code> for fallback) then it wouldn't serialize. It used the members marked as <code>[DataMember]</code>, using the explicit name on the attribute if specified, or the member-name otherwise. Life was good.</p> <p>More recently, the code was changed allowing "regular" types to be serialized - meaning: those without data-contracts. It does this using the same approach as <code>BinaryFormatter</code> uses - i.e. it works at the <strong>field</strong>-level. This is IMO bad:</p> <ul> <li>fields are the implementation, not the contract</li> <li>it is brittle if you change... anything!</li> <li>it doesn't hold much water against obfuscation</li> <li>something as innocent as switch to/from an auto-prop break it (auto-props have truly bizarre field names, that can't be emulated in regular C#)</li> </ul> <p>I know <em>why</em> this was tempting (to allow WCF to transport arbitrary types), but every sinew in my body says this was a net loss. It is much better to make people use the right tools (data-contracts) than it is to let their broken classes work. In the original 3.0, there would have been an exception thrown <em>telling</em> you how to fix this correctly: mark it as a <code>[DataContract]</code> and tell it which <code>[DataMember]</code>s you want to serialize.</p> <p>See also: <a href="http://marcgravell.blogspot.com/2009/03/obfuscation-serialization-and.html" rel="noreferrer">Obfuscation, serialization and automatically implemented properties</a></p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload