CODEWITHSUNDEEP
c#attributesreflectordisassembly
Richard Ev
Richard Ev

Reputation: 54167

Order of attributes in disassembled code

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?

Upvotes: 3

Views: 990

Answers (2)

jason
jason

Reputation: 241789

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.

Upvotes: 6

thecoop
thecoop

Reputation: 46158

The order of attributes does not affect the semantics of the code, and is simply an artefact of how the C# compiler compiles a project. it's probably chaotic emergant behaviour depending on what else is in your project. There's not much you can do about this, unfortunately...

Upvotes: 0

Related Questions