C# App: Binary Serialization File Size Allocation

[dantz]

hi, I would just like to know if there is a way to manually calculate the size of my structure to anticipate the file size of the object after serialization?

Is it reliable to depend on the file size of the usual result after serializing a certain structure? I mean, if I serialize an object then get the size of the result, will the result on the next serialization will still be the same even I change the data inside the structure?

What I am trying to achieve here is to serialize multiple objects but assign a specific block/position for them inside a file.

I hope I delivered my questions clearly that someone could help me.

Thanks in advance.

[Plater]

I think it depends on your structure?
If you only use hard sized Types (ints, bytes, etc) then I think it is fine.
But if you have an array ([] or string or Collection type) then I think the size of the serialized object will be different?
Might be better to have a "table" header at the begining of the file that points out where the offsets are?

[dantz]

Thanks for the reply.
But I still want to know the exact amount of bytes that my structure can consume.

I was trying to test a specific structure with a single property of int.
Please have a look on the code below.

public class GameState : ISerializable
    {
        private int inttest;
        public int IntTester
        {
            get { return inttest; }
            set { inttest = value; }
        }
 
        //private GlobalState _gstate = new GlobalState();
        //private PlayerState _pstate = new PlayerState();
 
 
        public GameState() { }
        public GameState(SerializationInfo info, StreamingContext ctxt)
        {
            inttest = (int)info.GetValue("IntTester", typeof(int));
        }
 
        public void GetObjectData(SerializationInfo info, StreamingContext context)
        {
            info.AddValue("IntTester", inttest);
        }
    }
 

This structure consumes 151bytes.
If I only have "int" inside that should consume only 4bytes,where did the other remaining bytes came from? Will this 151 bytes be enough to depend on(structure size will always be the same) that it will not change in the future for whatever reason?


Thanks in advance.

[Plater]

Serialization seems to be boggling a lot of minds lately.
You have to remember that serialization is supposed to be bi-directional. You are supposed to get the exact same object back. All the other bytes are data used to describe that exact class type.

Consider:

public class myclass1 : ISerializable 
{ 
  public int myint=0;
}
public class myclass2 : ISerializable 
{ 
   public int myint=0;
}
 

If it only stored the value of the int, how would it know which class to instanciate in memory when you reloaded it?

[dantz]

For that I was thinking that I need to create a separate function that checks the Type of the return object in Deserialization and a function that converts that object into its own type.

Do you think it is a good workaround?
I cant think of other idea,please let me know if you have one or any reaction on that.

I am really stuck into implementing serializing/deserializing any objects so my functions must most of the time dynamic.

Thanks in advance.

[Plater]

Well I am not an expert on serialization, but there are [attributes] that you can apply to your class I think to determine how(and what?) it serializes. Then you use the built in functions to recreate the object?
I don't think you need to do really any work about deciding what class it is, the built in deserialized portion should be able to do it

[mldisibio]

When you serialize, two things happen:
1. The actual members are written to disk. If these are fixed-size value types, they should occupy the same amount of bytes each time.
2. Meta-data about your class is written to the serialization stream. As Plater said, the meta-data is used to determine the exact source object that needs to be re-created. This includes the assembly name, version and other reflection data. My opinion would be not to rely on that always being the same number of bytes. It probably would be the same if you never recompiled the assembly.

While the serialization attributes allow you to control which members are serialized or not, it will not be as easy to control what meta-data is written to your serialization stream.

Dantz, I think what you want to do is write only the member data to file (for example, your int field) and then on reconstruction, you are simply creating a new object and filling it with the data which was stored to file. Your code takes on the responsibility of knowing what object to create, rather than the serialization. To do so, you might add a "fixed-length" field which indicates the object type.

So you are "emulating" serialization, but you would not be using the built-in serialization libraries of .Net. Nor should you try to "override" the serialization methods. You need to decide if this work-around is what you want, but .Net serialization always needs the meta-data of the object it is dealing with.

[RedSon]

Also, don't forget you can write your own serializer and control it how you like.

[dantz]

Thank you for your replies and happy new year to all!

RedSon:
That idea sounds good, I think I may give it a try but with limited time I hope I can finish soon. :)

mldisibio:
For #1 I tested all of my structures and it all give the same sizes even for strings. So now I just use that size then double it(for safety reasons) to be able to get anticipate the size of my structure.

For #2 Yes that is what i want to do. I will try your suggestion then just get back if there are still problems but I think I achieve what I want based on all your opinions.

Plater:
Ok, I will check on those [attributes]


Again, thank you for all your replies.