0

we had a developer leave after pushing VB asp.net 2.0 code to production, and now that we need to make changes, it's not at all clear which (if any) available version of the source code matches what was deployed to production.

This problem is somewhat similar to this previous question: Decompile Precompiled Source Code ASP.NET except that I want to, if possible, determine whether the production deployment exactly matches one of the versions of source code we have.

Among the things I've tried:

  1. 1) I tried to use various tools for a directory-by-directory, file -by file recursive comparison of .aspx files in the source and in production. But the compilation process changes the headers just enough that they no longer match the files from before compilation, and I've not found a tool that can filter out this difference. And this would not be sufficient anyway.
  2. 2) I've tried to decompile the production code to VB, and compile the source, and then decompile it to VB as well. This leaves me with two sets of decompiled VB source code to compare as above. I used Redgate Reflector and Denis Bauer's File Disassembler add-in to produce the source code. The problems with this approach: The decompiler put in different variable names for each code set, so all files were different, at tons of places that involved the use of a variable.
  3. 3) I used reflector with the Diff addin by Sean Hederman. This should just diff the source code within the .dlls for us. The difficulty here was that the large project is spread across 5 or more .dlls at compile time. These .dlls appear to be given random names, and the same code file might be compiled into one .dll on one compile, and into another .dll on another compile. The Diff add-in appears to just compare one .dll to one other .dll, so this is too big a scope for this tool.
  4. 4) Redgate has an "export" feature that will export the source within a .dll to a directory full of source files. Thinking this might give different results than the add-in approach in item (2) above, I tried it as well. This time, I exported the code in IL, since I thought that might differ less than the VB source did. In fact, the IL produced by the compilers is radically different even when I think the source files were probably the same (since the files decompiled to C# looked the same except for the differing variable names.)
  5. I've also investigated a number of other decompiling tools, but none seemed to offer the ability to decompile such a large project to a number of source code files that could be compared.
  6. I looked for files/.dlls that had an identifiable version number before I tried any of the above, to see if the version number could be matched with production. I've yet to find one.

Does anyone have any ideas/tools/strategies that could resolve this once and for all? Many thanks!

Community
  • 1
  • 1
1010100 1001010
  • 1
  • 1

1 Answers1

0

Instead of trying to decompile production to see if it matches the source, could you go the other direction? Retrieve each version of the source, compile it, and then compare the results to what's in production - if you end up with a matching set of files, then that's likely the version used for what's in production.

Assuming that the versions are in some sort of source control system, you can probably even script out the "checkout, build, compare" process.

E.Z. Hart
  • 5,717
  • 1
  • 30
  • 24
  • Hi, thanks for the feedback. I've done what you suggest, but it does not show differences in the source files. That is to say, I can change a source file without changing the resulting compiled code, and thus without producing a noteworthy difference between this code and the deployed code. – 1010100 1001010 Feb 14 '12 at 00:30
  • Any other ideas as to how I can determine which, if any, of these versions of source code was used to produce the deployment? – 1010100 1001010 Feb 14 '12 at 00:33
  • It turns out my answer probably won't work anyway - compiling the same source code twice does not guarantee the same resulting assembly, at least not for the purposes of doing a diff: http://blogs.msdn.com/b/ericlippert/archive/2012/05/31/past-performance-is-no-guarantee-of-future-results.aspx – E.Z. Hart Jun 07 '12 at 15:41