How can we help you today? How can we help you today?

Disassembly not as expected - Freddy Starr ate my var names!

So after a hard-drive crash I've lost some changes that hadn't been checked into VSS. I thought I'd decompile the relevant DLLs but it's giving me some unexpected results.

e.g. Original code:
strSQL = "DELETE FROM template_variations ";
strSQL += "WHERE client_id=" + objGlobals.getClientInfo().getID() + " ";
EdeptiveSystem.dbExecuteNonQuery(strSQL, objGlobals.getSqlConnection(), null);

Decompiles to:
strSQL = "DELETE FROM template_variations ";
object CS$00000002$00000000 = strSQL;
EdeptiveSystem.dbExecuteNonQuery(string.Concat(new object[] { CS$00000002$00000000, "WHERE client_id=", base.objGlobals.getClientInfo().getID(), " " }), base.objGlobals.getSqlConnection(), null);

It's doubtless functionally equivalent but is this to be expected? It's a bummer when trying to use diff to find the new code.

Any thoughts? Thanks :)
jeromewilson
0

Comments

5 comments

Sort by
  • odalet
    It looks like an optimization, but I am not sure.

    I suppose the DLL you fed Reflector with was a Release one, maybe a 64bits?
    odalet
    0
  • jeromewilson
    Thanks for the reply Olivier. I'm sure you're right - that it's optimisation. The thing is, I could have sworn that it was a debug build, 32bit. I'm not sure if debug builds still perform optimizations, I wouldn't have thought so, given the necessity to match line for line with the source when debugging, but I guess maybe the PDB sorts that out...
    jeromewilson
    0
  • odalet
    Now, I'm not so sure I was right:

    I've tried similar code, in debug and release mode... same result in Reflector, and no CS$ stuff...

    And, unless you modify your project's Build properties, debug mode comes with no optimizations.
    odalet
    0
  • jeromewilson
    Hmmm, it's strange isn't it? It was compiled on my machine, copied to a bin directory on a server (64bit) and then copied back to my machine to be decompiled.

    Oh well, if you happen to have any thoughts sometime about what might have caused it, it would be great to hear them :)
    jeromewilson
    0
  • haleyjason
    When it seems the Reflector is returning something unexpected in the decompiled languages (C#, VB, etc) change it to IL and see what it looks like. The IL is a straight disassembled representation of the exe/dll so if the IL code looks odd then the strangeness is in your compiler ... not the decompiler. Sometimes its hard to track down which one did or didn't do an optimization.

    Depending on the complexity of your assembly, you might try roundtripping the exe in ILDasm and strip out the debug info ... the debug builds can add alot of code to enable a user to put break points on every line of source code ... and even more in 2.0 + due to multiple statements in one line of source code.
    haleyjason
    0

Add comment

Please sign in to leave a comment.