serializing an object to a string

[Marco Herrn]

Hi,

I need to serialize an object into a string representation to store it
into a database. So the SOAPFormatter seems to be the right formatter
for this purpose. Now I have the problem that this formatter writes into
a stream. And I am not used enough to C# to convert this to a string.
I tried the following code:

MemoryStream stream= new MemoryStream() ;
IFormatter formatter = new SoapFormatter();
formatter.Serialize(stream, o);
byte[] buffer= stream.GetBuffer();
stream.Close();
UTF8Encoding encoding = new UTF8Encoding( );
string s= encoding.GetString(buffer);

stream= new MemoryStream();
encoding= new UTF8Encoding();
buffer= encoding.GetBytes(s);
stream.Write(buffer, 0, buffer.Length);
formatter = new SoapFormatter();
object o2= formatter.Deserialize(stream);
stream.Close();

That should serialize and deserialize the object. But I get the
exception "XmlException: The root element is missing." on
formatter.Deserialize(stream). Now I do not know what the problem here
is. When writing the string to a file it seems that there are
non-character bytes at the end of the string. I do not know whether this
really is the problem here, so I hope someone can point me to the right
direction.

Another problem is: Is UTF8 Encoding the correct one? Would be another
encoding more appropriate?

Regards
Marco

 

[Helge Jensen]

formatter.Deserialize(stream). Now I do not know what the problem here
is. When writing the string to a file it seems that there are
non-character bytes at the end of the string. I do not know whether this
really is the problem here, so I hope someone can point me to the right
direction.

GetBuffer can return a byte[] that is longer than what you have written.

Another problem is: Is UTF8 Encoding the correct one? Would be another
encoding more appropriate?

There is probably no reason to even set the encoding.

You code should probably not construct a new memory-stream and write the
nuffer to it. you can use the MemoryStream.MemoryStream(byte[] buf, int
index, int count) to create a "view" of a buffer, so you don't have to
copy the content.

I seem to recall that SoapFormatter may be leaky. For the test, it's
fine to create a new one for each serialization, but you may wish to
consider sharing the IFormatter between invocations for the real code.

I would try code roughly like:

void testSerializer(object o) {
byte[] bytes;
int length = 0;
// Write
using ( MemoryStream ws = new MemoryStream() ) {
new Soapformatter().Serialize(ws,o);
length = ws.length;
bytes = ws.GetBuffer();
}
// Read
using ( MemoryStream rs = new MemoryStream(bytes, 0, length) )
object o2 = new SoapFormatter().Deserialize(rs);
System.Diagnostics.Debug.Assert(o.Equals(o2),
"Deserialization gave non-equal object");
}

 

[Marco Herrn]

Hi Helge,

There is probably no reason to even set the encoding.

But when converting the byte Array to a string I need to use a Encoding.
Or is there a different way of this conversion?

Thanks for your code example. It works. But still lacks the conversion
to a string. How can I convert the buffer _without_ converting the extra
bytes at the end?

Regards
Marco

 

[Helge Jensen]

Hi Helge,
Hi.

I don't think any *particular* encoding is appropriate.

A good choice would be the one the SoapFormatter uses, but it's really
not required.

But when converting the byte Array to a string I need to use a Encoding.
Or is there a different way of this conversion?

Can't you store the serialized object without conversion? You are
introducing an interpretation.

Try thinking what about what would happen if you chose Base64
en/de-coding for the conversion between byte[] and string. It would
work, since the encoding of the xml-document is independent of the
string<->byte conversion.

You could look into the serialized byte[] and choose an encoding based
on the xml encondig-declaration (it would be the identity encoding), but

Thanks for your code example. It works. But still lacks the conversion
to a string. How can I convert the buffer _without_ converting the extra
bytes at the end?

I think you should go out of your way, not to do that conversion.

 

[Ollie Riches]

FYI SoapFormatter is going to become obsolete in the next version of .Net


--
HTH

Ollie Riches
http://www.phoneanalyser.net

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a programmer
helping programmers.

 

[Marco Herrn]

Hi,

Can't you store the serialized object without conversion? You are
introducing an interpretation.

The reason I am trying to do this is to store the serialized object in a
database. Therefore I want it in string form. Maybe there are better
solutions to do this. Do you have any idea how to achieve this?

Try thinking what about what would happen if you chose Base64
en/de-coding for the conversion between byte[] and string. It would
work, since the encoding of the xml-document is independent of the
string<->byte conversion.

Hmm, sounds good. Do you think base64-encoding it, would be a solution
to my problem? I still would have to generate a second byte[] that omits
the trailing bytes. Otherwise I would have to store the length of the
actual object too to be able to deserialize it.

Regards
Marco

 

[Helge Jensen]

The reason I am trying to do this is to store the serialized object in a
database. Therefore I want it in string form. Maybe there are better
solutions to do this. Do you have any idea how to achieve this?

BLOB, it stores chunks of bytes in most databases.

Hmm, sounds good. Do you think base64-encoding it, would be a solution
to my problem? I still would have to generate a second byte[] that omits
the trailing bytes. Otherwise I would have to store the length of the
actual object too to be able to deserialize it.

I don't understand why you would need the length separatly. You
serialize (via MemoryStream) to byte[] and encode that as base64, store
in DB.

To read back read entire string, decode from base64 to byte[], create
new MemoryStream(decoded, 0, decoded.Length), and run the deserializer
on that.

Beware, the strings are probably gonna be pretty big.

An alternative way is to store the objects on disk (which nicely removes
need for MemoryStream, that is likely to spend mem on the
large-object-heap when serializing) in files, and just let the DB
contain items (paths) identifying the files.