 |
|||||||||
|
|||||||||
|
|
Here's the situation: You've written a service that is exposed via POX endpoints. You have a class and all of its members are happily marked as DataMember so you think you're in the clear. You then create a list of those instances like so:
List<MyClass> theList = new List<MyClass>();
theList.Add(new MyClass("prop1", "prop2", "prop3", "etc"));
And then you dump that class into your response with the following code:
response = Message.CreateMessage(message.Version, message.Headers.Action, theList);
Here's where it gets ugly. You go to hit your service at http://server:port/service and IE gives you an error that makes it look like you're not connected to the internet. VS 2005 doesn't throw any exceptions, and WCF doesn't send a serialized fault down to your client - so what in the hell is wrong?
The problem is what I think is a bug. In my opinion, the call to CreateMessage must ensure that anything sent to the last parameter (the object to be stored in the body of the message) should be serializable marked with the DataContract attribute. The reason being is that WCF will never send your HTTP client any information if the contents of the body of the message are not marked as DataContract. In my case, my class (MyClass) had all its members marked as DataMember but the class wasn't marked as DataContract. I would expect that the call to CreateMessage would throw an exception if I attempt to give it a list of items that are not serializable via WCF.
Here's a quick unit test that you can do to force an exception to be thrown if your message isn't going to be serialized, which is far more useful than the crappy "no connection" nonsense you get now. Right before you do a return response; before handing control back to your ProcessMessage method (assuming you're following the same naming convention as in the POX samples in the SDK), drop one of these in:
List<MyClass> unitTest = response.GetBody<List<MyClass>>();
If that passes, you know that your message is serializable and can be properly transmitted over HTTP. If that line of code fails and throws an exception, then you'll be given the exact reason why your message cannot be transmitted instead of letting WCF throw up its hands and deny a connection to calling clients.
I know its a bit obscure, but if you're doing POX messaging with WCf, you're going to run into this issue at least once, I can guarantee it. Hopefully this helps someone!
Happy POXing!
So, according to Microsoft, the "lazy" feature of CreateMessage is
intended. That's fine by me, the problem I have is that it doesn't throw an
exception or give you a fault when you attempt to return an unserializable
message to the caller via POX endpoints. It should dump an XML fault over
the wire to indicate something went wrong instead of simply refusing to
reply.
