Answered by:
Strange Behavior

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 AMModerator
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.
- Marked as answer by Paul IshakModerator Saturday, August 11, 2012 8:15 AM
Saturday, August 11, 2012 8:15 AMModerator
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.
- Marked as answer by Paul IshakModerator Saturday, August 11, 2012 8:15 AM
Saturday, August 11, 2012 8:15 AMModerator -
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 AMModerator -
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 AMModerator