locked
Strange Behavior RRS feed

  • Question

  • In an effort to answer another posters thread, I have discovered some strange behavior(or let me know if I'm wrong) inside vb 2010

    Let me attempt to explain. I have listed a GIANT string of bytes that are derived from a compiled version of a separate project. I then convert this string of bytes into an array of bytes and invoke it using the reflector. Bear in mind that the embedded "filescan" utility originates from COMPILED code, and is embedded as a string of bytes. When I invoke the method(using load raw bytes[the compiled bytes]) then when I run the scan utility, if I quit while a threaded operation is in progress and it tries to invoke a disposed control, naturally I get an error, and the program throws an exception. My question is why is the designer revealing the source code for the compiled and embedded app. Please download the project and run it. Please note it will run, but it takes a minute to process the embedded bytes, so be patient. This is indeed an interesting find. I do not think microsoft intended to de-compile.

    The source code for the embedded program does not exist in this project, only the bytes of the compiler generated exe file.  Why does vb decompile?

    Paul's Skydrive - Strange Behavior.Zip


    If you want something you've never had, you need to do something you've never done. If you believe something to be true, then one day you will be called upon to demonstrate that truth.

    Saturday, August 11, 2012 7:08 AM
    Moderator

Answers

  • OK, I figured it out, I guess its because inside the embedded exe, was also embedded the path to the original source, hence you probably couldn't replicate it anyways. I changed the name of the original source directory, and it no longer supplied source code when the exception was thrown.


    If you want something you've never had, you need to do something you've never done. If you believe something to be true, then one day you will be called upon to demonstrate that truth.

    Saturday, August 11, 2012 8:15 AM
    Moderator

All replies

  • OK, I figured it out, I guess its because inside the embedded exe, was also embedded the path to the original source, hence you probably couldn't replicate it anyways. I changed the name of the original source directory, and it no longer supplied source code when the exception was thrown.


    If you want something you've never had, you need to do something you've never done. If you believe something to be true, then one day you will be called upon to demonstrate that truth.

    Saturday, August 11, 2012 8:15 AM
    Moderator
  • It must have something to do with how the debugger catches errors, and the embedded file crashed, the debugger looked somewhere in the actual bytes of the embedded file, and found the path to the form's source code in the other project, and opened a new tab thinking it was actually part of this project, because it was executed from this project.

    If you want something you've never had, you need to do something you've never done. If you believe something to be true, then one day you will be called upon to demonstrate that truth.

    Saturday, August 11, 2012 8:22 AM
    Moderator
  • Glad to see you have found another solution and thanks for sharing.

    Best regards,


    Shanks Zen
    MSDN Community Support | Feedback to us

    Thursday, August 16, 2012 8:51 AM
    Moderator