icsharpcode
ilspycmd: support ILSpy decompiler options, e.g. stable attributes ordering
Using: ilspycmd 9.1.0.8007 from latest HEAD 57cd68fc1ffff48d8307d304e321e4de07d3394d as of today.
Problem
I'm decompiling a (private) program across updates and reviewing the differences. The program uses attributes, and for some surely valid technical reasons either on the compiler or decompiler side, the order changes in the decompiler output.
Example 1:
[A]
[B]
void Method()
Example 2:
[B]
[A]
void Method()
Diff:
-[A]
[B]
+[A]
void Method()
This produces unnecessary noise in the difference, because nothing significantly changed. I'd like to reduce this noise to make code reviews across updates easier.
According to the C# attribute specification, the order is not significant:
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.
Proposed solution
Implement a stable attribute ordering, for instance a regular alphabetical sort.
If you agree in principle, I'd be happy to work on this and send a pull request. However, I'm not familiar with the codebase, so I welcome any pointers where the code changes would be best made.
Thank you!
@christophwille do we have a good strategy to get this into ilspycmd as well? I don't think it's sustainable to always keep patching this on demand.
Thanks Siegfried for the quick reply. My bad, but good news, didn't realize this was already done! So it's just a matter of plumbing it from ilspycmd (like a cmd line flag) to the decompiler object options? I'll wait for Christoph's response.
Any reason why we shouldn't make this the default? (at least for ilspycmd, but maybe ILSpy too) Unlike some of the other options, it doesn't seem too controversial given the specification's position on ordering being non-significant. I doubt anyone would rely on non-ordering, but, who knows.
One way would be eg --use-decompilersettings pathtosettingsfile where %userprofile%\AppData\Roaming\ICSharpCode\ILSpy.xml is available when ILSpy is on the machine as well. Providing --option-A to --option-ZZ is maybe a bad approach and might mean constant catching-up.
If we go with that, maybe a --generate-decompilersettings pathtosettingsfile might be useful as well to get a file with all defaults and then modify to your liking. (ilspycmd might after all be used without ILSpy)
That sounds reasonable, thanks Christoph!
I agree --option-A while convenient for users would be a maintenance nightmare for the developers, unless we find some way to automatically generate them (let me know if you'd like me to explore that, in principle).
Alternatively a --generate-decompilersettings pathtosettingsfile is a good idea to make it at least simpler for cmdline-only users to start with something.
Let's stick with the simple reuse of the settings file for now - if it turns out not to be enough, we can always start adding more options.