When inspecting disassembled code that has been exported using .NET Reflector I have noticed that the order of attributes on any given entity is not always maintained.
I've seen this when comparing the disassembled code of two versions of the same assembly (that has seen some minor code changes between the two versions), in classes that have not actually changed between the versions.
e.g.
[WebBrowsable, Personalizable]
public int SomeProperty ...
vs
[Personalizable, WebBrowsable]
public int SomeProperty ...
This is pretty inconvenient as it makes it look as if files that have not changed, have.
What controls the order of attributes in this scenario, and is there anything that can be done to maintain the order?
Per the specification
The order in which attributes are specified in such a list, and the order in which sections attached to the same program entity are arranged, is not significant. For instance, the attribute specifications [A][B], [B][A], [A, B], and [B, A] are equivalent.
That doesn't quite say that there is nothing that can be done to maintain the order, but it does say that the compiler doesn't have to pay attention to the ordering of the attributes and thus is free to reorder as it see fit. If you want to guarantee the ordering, you are probably going to have to modify the assembly post-build. There is probably a simpler way to solve your problem.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With