views:

643

answers:

2

I'm getting the following error when I try to Serialize an HttpWebRequest

Type 'System.Net.KnownHttpVerb' in Assembly 'System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' is not marked as serializable.

Using .Net Framework 2.0

This is one of the properties that my class holds. It's a requirement to serialize it.

HttpWebRequest is marked as Serializable so it supposed to Serialize

+2  A: 

Well, if one of the contained objects is marked as non-serializable, I believe you're "out of luck" using the default serializer.

If possible, I would recommend instead taking the parameters used to instantiate your web request and serializing those instead. Write a custom serializer/deserializer to reconstitute the uncooperative object.

EDIT: There's a fairly good article on it here.

EDIT2: In fact, after a little googling, it appears that this is your only option, as the Serializable attribute on HttpWebRequest has been marked obsolete as of .net 2.0. See here for details (search for HttpWebRequest).

Andrew Rollings
HttpWebRequest is marked as Serializable so it supposed to Serialize
dr. evil
What is SOL? I use binaryformatter to serialize.
dr. evil
Well, the HttpWebRequest class apparently contains a System.Net.KnownHttpVerb which is *not* serializable. That's what is causing the problem.And I'll edit SOL to make it clearer.
Andrew Rollings
LOL - SOL - its a new framework ;-)
stephbu
I don't see why MS made it obsolete, It's my seriliazer and I was happy with the size overhead, it's so much easier than writing more code :)Anyway thanks for the answers and Thanks to MS!
dr. evil
It makes sense because most of the instance represent temporal artifacts like the underlying socket and related transmit/receive buffers. These cannot be de/rehydrated. The bug was marking it as serializable in the 1st place.
stephbu
A: 

System.Net.HttpWebRequest serialization was marked as obselete in .NET 2.0.

Official documents here:

http://msdn.microsoft.com/en-us/library/aa497288.aspx

From an app perspective this is the best outcome. The predominant bulk of an HttpWebRequest instance is IO state that is typically not directly rehydratable.

As @Andrew-Rollings suggests instead implement a custom serialize to store/restore your request parameters, then recreate the HttpWebRequest instance from scratch.

stephbu