Fields initialized in the constructor should not be ordered by token.

[CreateAndInject]

Is this bug present since ILSpy’s inception, or was it introduced by a specific commit?

[siegfriedpammer]

Do you have an example? I think this would be easily caught by our tests.

[CreateAndInject]

demo.zip

Fields of Program

[siegfriedpammer]

I believe that this is due to obfuscation + deobfuscation... is this reproducible just using a Microsoft compiler? I believe the Microsoft compiler emits FieldDef tokens and field initializers in source order, therefore the order of tokens always matches the required initialization order. To fix this, we would have to calculate the order from the .cctor/.ctor and use it when emitting the fields.

To answer your first question: yes, I tried with ILSpy 2.4 and it has the same problem.

[CreateAndInject]

I think protector rebuilt the tokens

[CreateAndInject]

we would have to calculate the order from the .cctor/.ctor and use it when emitting the fields

@siegfriedpammer Seems it's not an issue? Just order of stfld/stsfld?

[siegfriedpammer]

we would have to calculate the order from the .cctor/.ctor and use it when emitting the fields

siegfriedpammer Seems it's not an issue? Just order of stfld/stsfld?

yes, but given it hasn't been an issue in the last 14 years and only occurs with obfuscated assemblies, it's not really high on my priority list currently. I will come back to this as soon as I have time.