Dynamic IL - Is this out of date?

[Korporal]

Years ago (2009) I coded this and it still works, but I wanted to ask is this "current" would something like this be coded the same way in .Net 8? I'm trying to get an idea of how dynamic IL has changed (if at all) over the past fifteen years.

[huoyaoyuan]

The IL itself doesn't change. However, there are several things to mention:

• Certain IL streams are not fully valid, but tolerated by old versions. There's no guarantee that they will continue to work. Generally, be explicit about type casting.
• Dynamic methods are not compatible with NativeAOT. There was an experiment to support interpreter with NativeAOT, but far from production.
• Your class manipulation code appears to have GC hole as the objects are not properly pinned. Unsafe.ByteOffset is more reliable.

[Korporal]

Thank you @tannergooding. The origin of this entire thread is, given a physical structure of memory layout, can we always define C# structs to correctly represent that layout. The physical layout of memory can be regarded as a contract, for example a COFF or ELF or GIF file contains numerous precisely ordered and laid out little structures. Does C# today allow me to always define a struct that can correctly describe and access such data?

I want to stress that no interop is implied here, typically one would have an unsafe C# pointer of some struct type and expect to be able to use that to access the various byte fields without the .Net runtime imposing its own order, padding, offsets or even alignments.

Bit fields are out of scope too, I'm not concerned with these, only the freedom to define structs composed of blittable types and nest such structures. The documentation for FieldOffsetAtribute implies this only applies to "unmanaged representation" but I can find no precise definition for this term.

@jkotas - you might have views on this.

[tannergooding]

Does C# today allow me to always define a struct that can correctly describe and access such data?

If you can define such a struct in C/C++, then you can define it in C# and it will work the same (provided you are only using blittable types). The C# struct definition will be essentially identical to the type define in C/C++, only using struct { } + [FieldOffset(0)] instead of union { }

If you can't define such a struct in C/C++, then you shouldn't be trying to define such a struct in C#. Instead, you should be using something more like a stream and binary reader/writer to ensure that the strict layout given is matched.

If you've ever looked at how something like the core PE reader used by the JIT or S.R.Metadata works, you'll note that it will use a struct in a few cases where that is possible. But there are many other cases it doesn't have a struct it can use and explicitly does binary reading to get the values it needs. There are also often concepts for these types of files like relative pointers which need helper APIs to compute where the next piece of data is read from.

I want to stress that no interop is implied here

Interop is very much implied here as interop does not just pertain to p/invoke. Interop very much applies to any scenario where you're trying to ensure .NET code works correctly with something that is defined outside of .NET, including things like reading COFF, ELF, GIF, JPEG, or other file formats.

[CyrusNajmabadi]

The physical layout of memory can be regarded as a contract, for example a COFF

For COFF reading, could you use PEHeaders?

[CyrusNajmabadi]

@tannergooding Note: i think @Korporal has a fixed target platform he intends to run on. So he may be willing to take a solution that is not fully portable, but works there alone. Though it would be good to get clarification from him on this.

[jkotas]

@jkotas - you might have views on this.

I do not have anything to add to @tannergooding's answers. Tanner covered every aspect of this problem space that I can think of.