Can viewstate serialize this class?

[Ben Amada]

I've created a class that I need to store in ViewState. However when I try
to store it in ViewState, I get the following error:

"The type 'solution.pe2' must be marked as Serializable or have a
TypeConverter other than ReferenceConverter to be put in viewstate."

I've included the <Serializable()> attribute, but I'm still getting the same
error.

The class is below ... as you can see it contains a Collection, two
Hashtables and an Enum.

How can I make this class and all of its contents serializable so ViewState
can store it??

TIA, Ben

-----------------------------------------

<Serializable()> Public Class pe2
Implements IEnumerable

Private m_colChildren As New Collection
Public Style As New Hashtable
Public Attributes As New Hashtable
Private m_strID As String
Private m_enumElementType As ElementType

Public Enum ElementType
Span
Div
Image
End Enum

Public Function GetEnumerator() As _
System.Collections.IEnumerator Implements _
System.Collections.IEnumerable.GetEnumerator

Return m_colChildren.GetEnumerator

End Function

End Class

 

[Kevin Spencer]

Yes, the SDK is a bit ambiguous with regards to the "marked as Serialzable"
references that seem to pop up in it from time to time. They are misleading.
In fact, either adding a Serializable attribute or not adding one does
nothing to make a class more or less serialzable. It is important, however,
in some cases, as the .Net platform has mechanisms for doing serialization
by using reflection.

Serialization, in this case, refers to converting data to a stream of text.
It can also refer to converting it to a binary stream, but that's not the
issue here, as we're talking about ViewState, which is text in an HTML
document. Some existing .Net classes are serialzable "straight out of the
box" (as it were). These include primtives and value types, integers,
strings, dates, you know what I'm talking about. Basically, any type that
has a ToString() method implemented which converts it to a string
representation of its Data is serializable. A few more complext types are
also "natively" serializable, including arrays of the previous types, some
Collections, and conveniently, DataSets and DataTables. These are types that
implement the ISerializable interface. For most other types, and custom
types, you will probably have to implement your own custom Serialization.
This is not necessarily difficult, however, with the Serialization classes
in the Framework, depending upon exactly what you want to serialize, and how
you want to serize and deserialize it.

One of the best (and easiest) ways to serialize a class is using the
System.Xml.Serialization NameSpace. Serializtion to and from XML is not only
one of the easiest things to do in .Net, but it also happens to be possibly
the best way to serialize data to text. XML is powerful stuff. An XML
document can be transformed on the fly to any format you wish, using XSLT,
and can include any type of data as well. It is cross-platform compatible,
and a highly popular world-wide standard.

The main class that you employ in the System.Xml.Serialization namespace is
the XmlSerializer. This class is used for both serialization and
deserialization, and has a really nice API. In most cases, you can serialize
an object by simply creating an instance of the XmlSerializer class, and
calling the Serialize method. All public fields, and public properties that
implement a setter and a getter are serialized automatically, using
Reflection. Methods are not. Note that the class must implement a
parameterless constructor to be able to do this. However, you can certainly
overload the constructor to your heart's content.

The methods are restored when you deserialize the class. You can read more
about XML serialization at:

http://msdn.microsoft.com/library/d...us/cpref/html/frlrfsystemxmlserialization.asp

You can read more about serialization without XML at:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/objserializ.asp

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

 

[Ben Amada]

Yes, the SDK is a bit ambiguous with regards to the "marked as
Serialzable" references that seem to pop up in it from time to time. They
are misleading. In fact, either adding a Serializable attribute or not
adding one does nothing to make a class more or less serialzable. It is
important, however, in some cases, as the .Net platform has mechanisms
for doing serialization by using reflection.

Serialization, in this case, refers to converting data to a stream of
text. It can also refer to converting it to a binary stream, but that's
not the issue here, as we're talking about ViewState, which is text in an
HTML document. Some existing .Net classes are serialzable "straight out
of the box" (as it were). These include primtives and value types,
integers, strings, dates, you know what I'm talking about. Basically, any
type that has a ToString() method implemented which converts it to a
string representation of its Data is serializable. A few more complext
types are also "natively" serializable, including arrays of the previous
types, some Collections, and conveniently, DataSets and DataTables. These
are types that implement the ISerializable interface. For most other
types, and custom types, you will probably have to implement your own
custom Serialization. This is not necessarily difficult, however, with
the Serialization classes in the Framework, depending upon exactly what
you want to serialize, and how you want to serize and deserialize it.

One of the best (and easiest) ways to serialize a class is using the
System.Xml.Serialization NameSpace. Serializtion to and from XML is not
only one of the easiest things to do in .Net, but it also happens to be
possibly the best way to serialize data to text. XML is powerful stuff.
An XML document can be transformed on the fly to any format you wish,
using XSLT, and can include any type of data as well. It is
cross-platform compatible, and a highly popular world-wide standard.

The main class that you employ in the System.Xml.Serialization namespace
is the XmlSerializer. This class is used for both serialization and
deserialization, and has a really nice API. In most cases, you can
serialize an object by simply creating an instance of the XmlSerializer
class, and calling the Serialize method. All public fields, and public
properties that implement a setter and a getter are serialized
automatically, using Reflection. Methods are not. Note that the class
must implement a parameterless constructor to be able to do this.
However, you can certainly overload the constructor to your heart's
content.
The methods are restored when you deserialize the class. You can read more
about XML serialization at:

http://msdn.microsoft.com/library/d...us/cpref/html/frlrfsystemxmlserialization.asp

You can read more about serialization without XML at:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/objserializ.asp

Hi Kevin,

Your reply has been very helpful. I started looking at the XmlSerializer
class in addition to XML as a way of persisting data. I discovered a couple
of problems however:

(1) I must have a parameterless constructor which you mentioned in your
reply - however, my class doesn't have one. This is not a big problem
however.

(2) My class contains two hashtables which it appears from some archived
posts that I found is not serializable via the XmlSerializer class. There
are some other classes that do support serialization of hashtables however.
I also got the feeling that it's possible that a future version of the .NET
framework (possibly v2.0) might support hashtable serialization via the
XmlSerializer class.

One rather large concern that I have is because I will be instantiating a
bunch of these classes (my classes), even if I do succeed in serializing the
classes, ViewState might become very bloated.

Fortunately, I'm just starting this project and nothing is set in stone --
so I'm still keeping an open mind on how to make this project work in an
efficient way.

Eventually, I'm going to have to store all of my class data in a SQL
database. I haven't even created or designed the database yet, but at this
point, I'm considering only using the class I created to a limited degree
and possibly reading and writing to the database on each postback to
retrieve and persist data instead of storing it in ViewState to keep the
amount of data sent to the client to a minimum.

Again, thanks for your suggestions -- I learned something new again!

Ben

 

[JIMCO Software]

Let me recommend that if you are going to use XML serialization, create one
instance of XmlSerializer and cache it for reuse. Each time that the
constructor for XmlSerializer is called, a new dynamic assembly is
generated. These assemblies are small (~12k or so), but they will be
scattered throughout system memory, thereby causing fragmentation. If you
get enough of them, you'll end up seeing OutOfMemoryExceptions due to an
inability to allocate large contiguous blocks of memory to grow the managed
heap.

If you cache a single instance of XmlSerializer, you avoid this issue. By
caching it, you can take advantage of cache trimming in cases where memory
pressure increases.

 

[john_teague]

ViewState does not support Xml object Serialization, it uses the
LosFormatter for serialization. You should use a BinaryFormatter with
a TypeConverter. You might be able to use the GenericTypeConverter by
adding this attribute to your class:
<TypeConverter(typeof(GenericTypeConverter))>
I've seen implementations with this, but I haven't tried it myself. It
will be much faster if you implement your own.

Take a look at this blog:

http://weblogs.asp.net/vga/archive/2004/06/09/ViewstateSerializationOneMoreTime.aspx

Given the number of collections you have in your class, I don't think
that ViewState serialization is wise. You will create a very large
viewstate field on the client and will create performance problems that
you have no control over. Consider serializing to Session (which will
accept XmlSerialization), Cache, or storing your stringId parameter and
hydrating the class from that value.

 

[Kevin Spencer]

ViewState does not support Xml object Serialization, it uses the

I should have thought of that. Of course, one could always add an
HtmlEncode() to the mix, but I'm sure the method you've outlined is better!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

 

[Ramkumar via DotNetMonster.com]

John
Your post is very informative. Being a relatively new comer to the .net
platform , I was trying to save my custom business object collection in
viewstate abd stumbled upon the error "....Collection must be marked as
Serializable or have a TypeConverter other than ReferenceConverter to be
put in viewstate"...
When searching on the web for this error, I saw numerous posts suggesting to
write a Typeconvertor and use it with the typeconverter attribute for the
collection as well as the custom object contained in the collection.
But I do see many posts discouraging from using view state as we might take a
performance hit. So, would it be better altogether to use the session to
store the custom collection? If so use the session, then I guess I will not
get this error when stoing this collection.
Also, can you elaborate a little more on the third option - "storing your
stringId parameter and hydrating the class from that value" ? I quite dont
understand it.

Thanks

 

[john_teague]

I was assuming (perhaps incorrectly) that the data for your object
represented data in a persistent data store (database, file, etc) and
that m_strID was a lookup key. In that case, you could save just the
string id and then retrieve your data using it. Obviously this is much
slower than saving the object in session and if that is an option I
would do that first.