Can you please guide me to the best way to use the .PDB file (and
source files) to step into the DNOA source code while debugging my
project wich is using the DNOA?
I would love to have that option, not for looking for bugs, but for
learning how it all works.
My solution so far has been to download the latest source code, build
my own DLL and PDB files, and then reference this DLL in my project.
The PDB file will then let me step into the DNOA source code.
But this way is not optimal for obvious reasons. I'd like to use the
"official" DLL in my project, and not one that I have compiled
myself.. I'm also having trouble with the fact that the DNOA dll is
signed, so I have to compile it unsigned for the DLL to work in my
project, and not give me errors about the signing (and that the source
code may be tampered with..)
Any help would be greatly appreciated.
Regards,
Terje Ulvestad
I've read somewhere that a PDB file contains path-info as to where the
original source code files where situated on the drive at the time the
project was built,
and so it is able to pick up the right files for me to debug even
though my project only references the dll (with the .pdb file also in
the bin folder).
But obviously the latest version of DNOA's PDB-file's recorded path
won't match the path where my copy of the source files are situated.
While debugging my project, the debugger is showing the dissasebly
window, with this path output on top: c:\TeamCity\buildAgent\work
\bf9e2ca68b75a334\src\DotNetOpenAuth\XrdsPublisher.cs
Do I need to put the downloaded source code anywhere special on my
drive, or do something else to "link up" the copy of the source code
files with my project containing the PDB file, to be able to step
througt the source code?
What am I missing out on here?
Thanks for your help! :)
Regards,
Terje
On Mar 11, 3:07 pm, Andrew Arnott <andrewarn...@gmail.com> wrote:
> Hi Terje,
>
> The PDB that is included with the download is for line numbers in exception
> stack traces and for stepping through source code as you say.
>
> What you need is the version of the source that matches the official release
> exactly. You can get this from github.com quite conveniently. For example,
> the latest release can be fetched from:http://github.com/AArnott/dotnetopenid/archives/v3.4.1.10044
>
> You can use "tags" in github to find the appropriate full version number for
> the version you have and download source that way.
>
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
Thank you very much for your time helping me with this, Andrew!
I deeply appreciate it, after all - you saved me a lot of hassle
here! :)
Regards,
Terje
On Mar 12, 1:36 am, Andrew Arnott <andrewarn...@gmail.com> wrote:
> Hi Terje,
>
> It's true that the PDB includes full paths to the source files. But when VS
> debugs and doesn't find the source file at the PDB-indicated location, it
> should ask you for help finding the right source file. You point it at just
> one of your source files that you downloaded, and VS will (generally) find
> the rest as needed automatically. If you're already in the disassembly
> view, you can use the callstack to "Go To Source Code" and prompt that "help
> me find the source code" dialog to come up. If even that doesn't work, VS
> may have already tried and failed to get you to help find the source code.
> At which point, right-click on the solution node, hit Properties, and one
> of the property pages includes a "source files to not look for" box. Empty
> that. Then try the above steps again.
>
> Hope this helps.
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
> 2010/3/11 terjeu <terje.ulves...@gmail.com>