DLL's In The Mirror
A while back, I mentioned how .NET Reflector can save your hide if you, say, compile a .NET DLL and then accidentally lose the associated source code and need to retrieve that new method you added. Then, today, I solved another messy problem by using Reflector and I thought the solution might be of use to others as well.
Here's the basic scenario where this problem exists. I had a DLL from production that I needed to modify. I went to the SVN repository to get the source, built it and tried running the application locally, only to run into all kinds of problems, even without making any changes.
I swapped out the production DLL and things worked OK (or at least *more* OK than the one I was building). Theoretically, the latest version of the SVN trunk should have been what was used to build the DLL that I grabbed from production.
Puzzled, I moved on to try the same DLL from dev, qa and staging, all of which worked, further compounding my confusion. Clearly, none of the DLL's from the server matched the source in the SVN trunk.
Enter Reflector and one of the handy add-ins. FileDisassembler which takes a DLL or EXE and dumps out all of the files from your compiled assembly. The resulting directory looks quite a bit like the structure of the original project (though not identical).
I used FileDisassembler to dump out a copy of the production DLL into a directory called "Production" and then did the same to the DLL that I had created into a directory called "SVN Source".
Since both directories contained decompiled code, the things that normally mess with "diff" tools: comments, whitespace, etc. don't get in the way (of course you don't get to see those either). So, I turned to WinMerge.
WinMerge lets you compare not just individual files, but whole directory trees, making it an ideal tool in this situation. I pointed WinMerge at both directories and slumped in my chair when I saw the results. Not just one or two differences, literally dozens of files (at least 75% of the C# files) were marked as different.
Worse, when I started checking the individual files, I found that something like 40% of the lines had differences. Many of them were clearly just someone refactoring the code: renaming a variable from "date" to "periodBeginDate" and the like, but there were other changes as well.
Dealing with untangling this mess is a task for later in the week, but this combination of tools turned out to be really handy, particularly if you're having to work on code you inherited from someone else.
Also, while you're checking out the add-ins, check out some of the graphing ones, which have proven useful in trying to get a picture of what goes on in the code. All of this stuff becomes really important when you're fixing bugs on code that neither you nor anyone else you can contact was responsible for writing the original code.
