Skip to main content
Home Forums Silverlight Programming Report a Silverlight Bug WCF & Silverlight - Why no call to the default constructor?
13 replies. Latest Post by Snympi on April 2, 2009.
(0)
Jason.Ja...
Member
10 points
15 Posts
11-25-2008 10:51 AM |
I've pasted a blogpost I made about this below (link to blog) (Please check out the example project that demonstrates the issue)
Can anyone explain why creating a default constructor (defined in a partial class) of an auto-generated Service References class for an object. Does not get executed when the object is created by a WCF service call?I'll go through some of the basic steps I did to reproduce this, and I'll attach the project I created to do so. I would love if anyone had some insight into this... SilverlightWcfConstructorTest.zip1. Create a web service that returns some complex type. (Class1)2. Create a Silverlight app that can consume the service above. (Use the Add Service Reference so it will auto-generate a service reference file).3. (in Silverlight) Create a partial class to extend the Class1 created by the service reference4. Add a default constructor to this partial class.5. Do something in this constructor to hint that it is called.6. Run it and see that the default constructor is never called when making a WCF Silverlight service call.
Can anyone explain why creating a default constructor (defined in a partial class) of an auto-generated Service References class for an object. Does not get executed when the object is created by a WCF service call?
I'll go through some of the basic steps I did to reproduce this, and I'll attach the project I created to do so. I would love if anyone had some insight into this... SilverlightWcfConstructorTest.zip
1. Create a web service that returns some complex type. (Class1)
2. Create a Silverlight app that can consume the service above. (Use the Add Service Reference so it will auto-generate a service reference file).
3. (in Silverlight) Create a partial class to extend the Class1 created by the service reference
4. Add a default constructor to this partial class.
5. Do something in this constructor to hint that it is called.
6. Run it and see that the default constructor is never called when making a WCF Silverlight service call.
ccoombs
Contributor
5018 points
743 Posts
11-25-2008 12:54 PM |
trace the code in the reference file back to where Class1 is created...
In EndDoWork:
SilverlightWcfConstructorTest.ServiceReference1.Class1 _result = ((SilverlightWcfConstructorTest.ServiceReference1.Class1)(base.EndInvoke("DoWork", _args, result)));
The silverlight client-side doesn't use the implicit default constructor in the autogenerated class to create it, and thus your overwrite in the partial class will never get called either.
11-26-2008 1:53 PM |
So there's no other way besides writing our own hackish/plumming to get classes to instanciate the way we expect classes in .net to be constructed? Is this an item on Silverlight's TODO list? or is there some special security reason for this?
11-26-2008 2:14 PM |
i'm not sure why you think the way this works is incorrect. this is how ws and wcf work; there's no security issue involved. you do realize that if you had an explicit constructor on the server that it would get called, right?
what are you trying to accomplish?
11-26-2008 4:41 PM |
Is this more related to Serialization in general? When an object is deserialized from (in this case) xml/soap the deserializer is by-passing the object's constructor... What I was trying to do was get the object to hook up to it's own PropertyChanged event w/out having to specifically call some "Initialize" method by it's controlling object to get the object into the state I want it. It would be nice to know that whenever I have this object it's already been wired up to it's own PropertyChanged event. We're building an app using the VMMV pattern and were trying to leverage the WCF generated classes as the M so we didn't have to write a bunch of wire-up to get the WCF objects into our domain model objects which contain some behavior... Is there an extensibility point I may be missing in the WCF stack that I could hook into and apply this so the VM/presenter object doesn't have to verify that the objects it gets back from a service are in a certain state or not?
sergey.k...
6 points
4 Posts
02-18-2009 9:19 PM |
02-18-2009 9:21 PM |
Yes in WCF you can use [OnDeserialized] attribute
Yes in WCF you can use [
But it haven't been included in SL2 runtime ;(((
Shame!
Snympi
15 points
10 Posts
03-09-2009 10:10 AM |
I'm having the same problem with the constructor. It has to do with the inability to extend the Notification system of auto-gen'd classes when WCF Web Services are consumed that got me to this point. It felt wrong to wire up the instantiated object's own PropertyChangedEventHandler in the first place and now I can't do it from the constructor because it does not get called. Could someone from MS please advise how (or if) the auto gen classes are supposed to be extended? Why make them partial in the first place?
jawc
46 points
55 Posts
03-10-2009 6:11 AM |
Oops....I got the same problem, too.....any suggestion to hook up the propertychanged event
03-10-2009 6:16 AM |
How the client-side object to be created? why the default constructor doesn't be called?
03-10-2009 6:50 AM |
OK, it's simple... before start deserialization runtime calls FormatterServices.GetUninitializedObject which creates instance WITHOUT calling any constructors... so forget all "constructors fire first" rules ;)and the thing is that so far I can't see any REAL reason for doing it that way... so silly IMHOPS. and yes, there is a workaround for controlling creation lifecycle ;) Hint - use DataMember's Order parameter ;)
03-10-2009 10:34 AM |
Dear Sergey,Thank you for your reply.
==>which creates instance WITHOUT calling any constructors... so forget all "constructors fire first" rules ;)OK...I will keep it in mind.==>use DataMember's Order parameter ;)would you mind I am asking for more detail, please?thank you
03-10-2009 10:48 AM |
I have searching around...and found the following information about
04-02-2009 7:06 AM |
The solution I have settled on is to implement the MVVM pattern. The ViewModel is now a completely seperate class that is fully under my control and I can extend it any way I see fit. The drawback of couse is that the proxy class that is created with the Web Service reference now has to be synchronized with my ViewModel when the web service call completes.
Not ideal, but it works.
WCF & Silverlight - Why no call to the default constructor?