Structs have been troublesome beasts in computer engineering for a very long time. Their memory layout is very hardware dependent. To make them efficient, their members must be aligned so the CPU can read and write their values quickly without having to multiplex the bytes to fit the memory bus width. Every compiler has its own strategy of packing the members, often directed by, for example, the #pragma pack directive in a C or C++ program.
Which is okay, but rather a problem in interop scenarios. Where one chunk of code may make different assumptions about the structure layout than another chunk, compiled by a different compiler. You can see this back in COM, .NET’s grandfather solution to interop programming. COM has very poor support for handling structs. It doesn’t support them as a native automation type but has a workaround through the IRecordInfo interface. Which lets a program discover the memory layout at runtime through an explicit declaration of the structure in a type library. Which works okay, but is quite inefficient.
The .NET designers made a very courageous, and correct, decision to solve this problem. They made the memory layout of a struct completely undiscoverable. There is no documented way to retrieve the offset of a member. And by extension, no way to discover the size of the struct. Everybody’s favorite answer, use Marshal.SizeOf() is not in fact the solution. That returns the size of struct after it is marshaled, the size you’d need to pass to, say, Marshal.AllocCoTaskMem() before you call Marshal.StructureToPtr. That arranges and aligns the struct members according to the [StructLayout] attribute that’s associated with the struct. Note that this attribute isn’t required for structs (like it is for classes), the runtime implements a default one which uses the declared order for the members.
One very nice side-effect of the layout being undiscoverable is that the CLR can play tricks with it. When packing the members of the struct and aligning them, the layout can get holes that don’t store any data. Called padding bytes. Given that the layout is undiscoverable, the CLR can actually use the padding. It moves a member if it is small enough to fit such a hole. You’ll now actually get a struct whose size is smaller than what would normally be required given the declared structure layout. And, notably, Marshal.SizeOf() will return the wrong value for the structure size, it returns a value that’s too large.
Long story short, there’s no general way to get an accurate value for the structure size programmatically. The best thing to do is to just not ask the question. Marshal.SizeOf() will give you a guesstimate, assuming the structure is blittable. If you need an accurate value for some reason then you could look at the generated machine code of a method that declares a local variable of the structure type and compare it to the same method without that local variable. You’ll see the difference in the stack pointer adjustment, the “sub esp, xxx” instruction at the top of the method. Of course, it will be architecture dependent, you’ll typically get a larger structure in 64-bit mode.