You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I wanted to use our implementation of JsonNet in WcfRestContrib for the standard content type application/json and create a new content type called application/dotnetxml for the standard DataContractSerializer (not using POX). I ran into problems because WCF by default intercept the application/json content type and sets the WebContentFormat to Xml (or it may have been Json, but the point is that it should be Binary). I also had the same issue when using a custom content type for DataContractSerializer, since the default for WCF for an unknown content type is Binary, but for the DataContractSerializer it must be Xml.
This then causes the DataContract implementations to fail because the message comes in with the wrong content/data type.
My fix was to create a ContentTypeMapper and wire that into the bindings under the WebMessageEncoder. That worked well, then I had to determine which content format each formatter needed. I extended the IWebFormatter in WcfRestContrib to have a property that returns the required content type, so long everything was good.
The main issue was how to get that data into my custom ContentTypeMapper. I couldn't find any live references during initialization that would let me do it. I ended up doing an ugly hack with a static dictionary in the mapper. I'm not too happy about that solution, it works, but ugly. Because of that I haven't created a public patch for that. If anyone has the same issue I'm happy to email the patch, but I don't think this should go into the main trunk in its current state.
The text was updated successfully, but these errors were encountered:
I wanted to use our implementation of JsonNet in WcfRestContrib for the standard content type application/json and create a new content type called application/dotnetxml for the standard DataContractSerializer (not using POX). I ran into problems because WCF by default intercept the application/json content type and sets the WebContentFormat to Xml (or it may have been Json, but the point is that it should be Binary). I also had the same issue when using a custom content type for DataContractSerializer, since the default for WCF for an unknown content type is Binary, but for the DataContractSerializer it must be Xml.
This then causes the DataContract implementations to fail because the message comes in with the wrong content/data type.
My fix was to create a ContentTypeMapper and wire that into the bindings under the WebMessageEncoder. That worked well, then I had to determine which content format each formatter needed. I extended the IWebFormatter in WcfRestContrib to have a property that returns the required content type, so long everything was good.
The main issue was how to get that data into my custom ContentTypeMapper. I couldn't find any live references during initialization that would let me do it. I ended up doing an ugly hack with a static dictionary in the mapper. I'm not too happy about that solution, it works, but ugly. Because of that I haven't created a public patch for that. If anyone has the same issue I'm happy to email the patch, but I don't think this should go into the main trunk in its current state.
The text was updated successfully, but these errors were encountered: