Firstly thanks for the reply!
It is the size is bigger than I expected because there is (I am
assuming) a rogue object that is keeping a reference to a contained
object that it shouldn't (if I serialize the same object tree twice
after significant processing the second serialization is larger than
the first). As such the serialization is actually pulling in too much
information (and so the larger size) - not a serialization bug, but an
implementation bug in one of the objects keeping a rogue pointer (or
so I suspect). Unfortunately due to the fact that the objects can be
dynamically added to the graph via a plugin architecture (and the
objects persist their own state) it is hard to determine where the
delta data size is coming from.
The best 'documentation' I've found is located
http://primates.ximian.com/~lluis/di...ion_format.htm
.. It appears however that the sscli20 has the implementation code for
the formatters so I could probably work it out from there - but that
is not something on my fun to do list!
The format is 'formatted', but just not in a human readable manner.
The deserialization knows how to read it, and reconstitute the
encapsulated objects. I'm only looking for the size of the objects :-)
So unless someone has written a 'summarization' reader of
binaryformatted to determine sizes and graphs of the data, and there
isnt a API to get the size of the individual data elements within the
stream I'll have to either write one - or poke around with notepad to
see what is being persisted and shouldn't be!!
On May 1, 9:09 am, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guard.caspershouse.comwrote:
Gareth,
I doubt there is, as the document isn't formatted.
Because it isn't formatted, I have to wonder how you are formulating the
idea that the serialized instance is larger than you expect. There is
nothing to base that idea on.
How big are the files, and what is the size that you are expecting them
to be? Also, is the file size really causing that much of a problem?
--
- Nicholas Paldino [.NET/C# MVP]
- m...@spam.guard.caspershouse.com