Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't change formatter for WCF-handled content types (HakanL) #1

Open
mikeobrien opened this issue Aug 11, 2010 · 0 comments
Open

Can't change formatter for WCF-handled content types (HakanL) #1

mikeobrien opened this issue Aug 11, 2010 · 0 comments

Comments

@mikeobrien
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant