I recently had a "castostrophy" where my entire project code was deleted except for the debug binary (because it was running and couldn't be deleted). I had a backup copy of the code from about 3 days prior, but a lot had changed in that time.
I am using dotPeek to reconstruct the deleted code, however I am afraid that I will miss some things - little bug fixes that I forgot about. I would like to be able to load the assembly from before the deletion and the one I am compiling now and compare the code - preferably the decompiled code. Now I could go through every class in both assemblies, copy the code to a text document, and then use a simple text comparison tool (like "diff") to look for differences. But it would be nicer if something better existed. One things that seems like it should already exist is the ability to export the decompiled code from an assembly to ".cs" files. This alone would save me quite a bit of time (I am not looking forward to copy-pasting 2* 50 or so files especially after what I already have to do).
Now if a direct comparison tool existed in the program, that would be even cooler! If one of the pay-for tools has this ability, that would be great as well.
Thanks for any assistance!
Thanks for the suggestion, however I'm not sure that it is really a decompiler-tool feature request, since there are lots of programs for comparing files and their content. Creating a dotPeek plugin for these needs sounds more logical.
Nevertheless, thank you for interrest in our products!
I understand that having a "diff" built-in program is a little over the top, especially for a free tool. This is not meant to be an all-in-one.
However, the ability to export all decompiled code from an assembly as CLASS.cs files in NAMESPACE folders seems like something it should have. This would actually avoid the biggest hassle for my situation - copying and pasting file content 100+ times.
You mention plugins. I didn't realize detPeek took plugins. Do you konw of an "export code" plugin?
I found this feature in the EAP version. It worked really well except some minor incosistencies. During one export inner classes were saved as a number then the enclosing type name (one I no longer had PDB for). In the other case it saved them with the inner class name (I had PDB for). In the case where I had the PDB it also followed the folder organization in my C# project while the other one was on a strict namespace orgnazation. In this case it would be nice to have the feature to tell it not to use the PDB (like you can when decompiling). In both cases it did not use the PDB for decompilation.
Thanks for a great product!