WCF HttpWebResponse Object Serialization in the Interface/Contract

I'm just about done with a WCF Service that allows me to "remote" database calls. One of the items we have in our contract is the ability to remote out HTTP requests.

Here's the interface:

[Operation_Contract()]
bool DoWebRequest( string url, out HttpWebResponse resp );

with the implementation (more or less -- no error reporting here):

public bool DoWebRequest( string url, out HttpResponse resp )
{
   bool done = false;
   resp = null;

   WebRequest req = WebRequest.Create( url );
   resp.Cr开发者_如何转开发edentials = CredentialCache.DefaultCredentials;
   resp = (HttpWebResponse )req.GetResponse();
   done = ( resp != null ? true : false );

   return done;
}

Then, I wrap this in a WCFServiceLibrary, host it in a console application, create a service reference in another application with a client to it. Then I wrap the client in another class and call it via client.DoWebRequest( url, out resp );

And all of my data access stuff works. However, when I try to use it in a test application, I get the following:

The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:00:59.7180000'.

I'm guessing this exception has to do with the fact that I'm not properly serializing the HttpWebResponse object in my interface definition. I could be wrong though. I'd appreciate help here on how to get this working.

As a side note, when I create the service reference, it swiched my parameters. The client Reference.cs file shows the method like this:

public bool DoWebRequest( out HttpWebResponse resp, string url )
{  
   return base.Channel.DoWebRequest( out resp, url );
}

Any ideas why? It's the only method with switched parameters. Could this be part of the problem? I can't figure out why the tool would do this, though.

Thanks again.

The HttpWebResponse object no doubt includes information that is only valid on the machine it comes from, like the network stream servicing the request. That information makes no sense to serialize.

You should abstract out what you mean by a Web Request and Web Response, and create objects that match those abstractions.