I have looked at many posts about how to accept an uploaded document in a WCF service REST endpoint. They say you should define the endpoint to have a single parameter with type Stream. Here is an example of one. I have implemented it as they suggest and it does work. Here it is in VB:
<OperationContract()>
<WebInvoke(Method:="POST", BodyStyle:=WebMessageBodyStyle.Bare)>
Function UploadDocument(data As Stream) As Stream
However, I am working with the additional constraint that this WCF service also uses SOAP endpoints. After adding this REST endpoint that accepts a Stream, the SOAP endpoints are breaking. The error in the SOAP response says
System.InvalidOperationException: For request in operation UploadDocument to be a stream the operation must have a single parameter whose type is Stream.
I am amazed that adding a REST endpoint would break these SOAP endpoints, but perhaps this would be more obvious for someone with experience in SOAP (I am new to it, as well as WCF Services). I looked that error up and found this post. This comment from Drew Marsh seems to be the fundamental problem here:
the WSDL generator implementation is made for the SOAP/RPC service contracts and on those you can't either have individual parameters of various intrinsic or data contract types, a Stream or a message contract. You can't mix the three together. So, when it tries to generate metadata for your REST service contract, where it's perfectly valid to throw a Stream parameter in the mix as the last parameter for the body, it bombs out with the error your seeing because it never expects to come across a signature like that.
I do not see any solution on that post or anywhere else I search. I tried making a <DataContract> class which has the document as a property with type Stream, along with the other form fields as properties, but when I try that I get the error
Unhandled InvalidOperationException in service: The incoming message has an unexpected message format 'Raw'. The expected message formats for the operation are 'Xml', 'Json'. This can be because a WebContentTypeMapper has not been configured on the binding. See the documentation of WebContentTypeMapper for more details.
Am I simply SOL if I want this REST endpoint to accept a multipart/form-data body? Or is there some way to make this work with all the constraints I'm working with? In case it makes a difference, yet another constraint is that this service is stuck in .NET 4.0, so that rules out some potential libraries that need .NET 4.5.
