Feature Request or Mod *COMPARE FILES*

[dem0nk1d]

The ability to take two files and do a 1-for-1 compare. Then find the differences in the source.

The current workaround is a little clunky.

Example

Load file CALC_V1.exe and dump as a project
Load file CALC_V2.exe and dump as a project

I then load up an application called WinMerge and compare the source differences, for changes between versions of the same file. Hope this makes sense.... It would be epic if this was built into dnspy.

Thanks -dk

[Lynnolium]

Good idea. I think some fields such as comments, white lines etc should be eliminated from the compare function. I also think the compare should be C# based rather than IL/hex. Interesting you mentioned WinMerge that is the program I use for that type of work.

Suggestion perhaps if its too big a project to add as a function maybe a plugin to use winmerge if installed?

[mitchcapper]

I think if dnSpy was to do anything towards this the best option would be to allow two assemblies to be selected and then provide some useful options to speed up the export to assist with review (ie some of the existing features like sorting member /function names and such). An external diff tool for the review though is almost certainly the best way to go as they are dedicated to compare work so would provide a far superior UI.

[ElektroKill]

Hi, this feature was already proposed as part of #51. I didn't yet comment on it so I might as well do it now, implementing this feature is hard. For finding the differences between two text inputs, we could utilize a library so that is not a problem. There are however other rather difficult things to consider when it comes to diffing .NET assemblies.

1. Compiler changes - The C# compiler has received and still receives a lot of changes to better optimize/add new language features. The current ILSpy 2.4 decompiler we are using is not very good at emitting consistent across compiler revisions. It is also really bad when it comes to debug builds where the C# compiler emits a lot of code to help in debugging and generating sequence points as it is unable to optimize this helper code away, leading to a mess of local variables, etc. which would lead to issues when comparing release vs debug assemblies. These issues should of course be partially or fully resolved when we move to ILSpy v7 engine which is being worked on.
2. Member ordering - While the C# compiler tends to emit members in the order they are present in the source code (sorting by RID of member gives us the original source code order of members), obfuscators may scramble the order of members which would make the comparisons yield unfavorable results. A way to get around this is to sort the members in alphabetical order which bypasses the metadata order. However, it does not account for member renaming which may be done by an obfuscator. It is also important to note that there are no ways to restore obfuscated symbol names besides guessing if we don't have the mapping file some obfuscators produce. If the order of members and their names are scrambled, with my knowledge of .NET, impossible to restore the original member order thus making comparisons between two assemblies virtually impossible.
3. This isn't really a concern with the actual diffing but rather the way it is presented to the user. Implementing a WPF control for displaying diffs while using the dnSpy text viewer should be possible but it would be very hard due to the complexity of the text viewer control dnSpy uses. We also run into various other complications as to which style of diff viewing we would like to use, inline view, split view, etc. Both of the aforementioned ways of showing diffs come with their own complications.

To summarise this is a feature I am interested in implementing however, due to its complexity it's currently not a priority of mine. As for alternative ways to diff assemblies current one could choose the most appropriate member sorting option in the decompiler settings, export two projects using dnSpy, and compare them using software like WinMerge. As for export speed, the export project option decompiles one class per CPU core so it shouldn't be a concern on modern hardware.

Comments, opinions suggestions welcome as always :)