WCF streaming is helpful in all those cases when you need to move a lot of data between
the client and the service in a way that keeps memory consumption under control
(see Large Data and Streaming on MSDN for
more details if you are not familiar with the topic).
Streaming does impose some restrictions. Among them is that your operations can only
have one input and/or output parameter and they can only be only one of the following:
a class implementing IXmlSerializable
I wanted to expose a very simple service to upload and download files through WCF.
And because I wanted to be able to pass both the file content as a stream and
at least the file name, I could not just use a Stream but had to resort to
the headers would convey the file information (such as the file type) and the body the content
of the file itself through a stream.
I therefore defined the service as follows:
I am omitting the details of the implementation, they are pretty straightforward
(if you are interested, I will gladly share it.
UPDATE: I have put the basic scheleton of the server implementation is a
And this is how the service was configured on the server side within the web.config.
This is the base of the plumbing that it's needed to create the service.
While I was developing it, I have lost quite some time for an error which was really obscure to decipher: Server Error in '/' Application. Operation 'UploadFile' in contract 'IFileTransferService' uses a
MessageContract that has SOAP headers. SOAP headers are not supported by the None MessageVersion.
Googling and binging around I found almost no relevant information on the topic, so I was pretty on my own.
I thought the problem was in the HTTP binding that I was using (maybe it was not compatible with SOAP headers?).
Unfortunately the HTTP binding did not have any way to specify a different MessageVersion.
So I ended up creating a custom binding,
like the following, but that didn't help either:
I made several other attempts with no luck. I then tried self hosting the service
and that did work. Then I was certain that it was something with the web hosting.
Tried IIS6, IIS7, etc... Same exception all the time.
To make a long story short, at the end, while reducing my web.config to the bare bones,
I found the culprit: it was the name of the service in the service configuration.