2

I am debugging a code and one strange thing occurs. There is a string property say MyProperty. When I add breakpoint at the setter of the property and at the default constructor ( The only constructor ) the setter is called first. I dont know what is going on at other level of the code but this seems strange to me in any case. All the members are non static. The class has a [DataContract] attribute and members are [DataMember]. Can anybody explain this?

I cannot share any more code than this. Also the code is in a Silverlight project.

Tanmoy
  • 44,392
  • 16
  • 45
  • 55
  • Is the constructor is called at all? – Simon Linder Mar 02 '10 at 12:22
  • 1
    You don't share any code at all. ;) But to me this sounds like you're trying to use the class, before you've created an instance. – Bobby Mar 02 '10 at 12:23
  • 4
    Write a small program to demonstrate the problem. It's probably not what/where you think it is. Right now this is hardly a real question. – H H Mar 02 '10 at 12:25
  • 2
    Why can't you post the constructor, the property code and the snippet that's showing the issue? You could change the names if necessary. – ChrisF Mar 02 '10 at 12:25
  • @Bobby: that would have given a null-ref exception. – H H Mar 02 '10 at 12:26

1 Answers1

5

Is this during WCF deserialization? In WCF deserialization, the constructor isn't called at all. That's by design. WCF objects are designed to be data transport objects, and any logic that resides behind setters and getters is dangerous at best. Chances are, you're seeing this behavior and concerned about it because you have something going on in business logic that resides in the setter. To work around this, I'd suggest decorating only automatic properties and fields with the [DataMember] attribute, which will prevent any other logic from being triggered. Also, be careful of any logic that would be performed in the constructor, that logic won't be executed during deserialization.

David Morton
  • 16,338
  • 3
  • 63
  • 73
  • 2
    Wow! that is surprising, have you got any references for that. I can't imagine how a serialisation scheme would not call a constructor yet assign property values via their mutator methods. – AnthonyWJones Mar 02 '10 at 12:31
  • Yes it is having WCF serialization I guess because we are using WCF services. – Tanmoy Mar 02 '10 at 12:37
  • I am adding validation logic at the setter like the following blog http://msmvps.com/blogs/theproblemsolver/archive/2008/12/30/data-validation-silverlight-versus-wpf-part-2.aspx and getting _errors null exception inside setters because of this reason. How can I work around this? – Tanmoy Mar 02 '10 at 12:41
  • 1
    @Anthony - it's true. Check out the OnDeserialized attribute for data classes, and this SO answer: http://stackoverflow.com/questions/178645/how-does-wcf-deserialization-instantiate-objects-without-calling-a-constructor/179486#179486 – slugster Mar 02 '10 at 12:43
  • I think you mean to say WCF DEserialization. – P Daddy Mar 02 '10 at 12:51
  • @Tanmoy - I mentioned how to workaround it in my post. Don't decorate any property that has any business logic at all. The only members that should be decorated with [DataMember] should be class-level fields and automatic properties. Your validation should occur when you initially set the values from outside serialization and deserialization, it shouldn't happen during deserialization at all. – David Morton Mar 02 '10 at 13:10
  • @slugster: Thanks for that. That's a gotcha I was previously unaware of. – AnthonyWJones Mar 02 '10 at 15:22