In my efforts to solve this, I started a completely new project which
consists only of a C# Windows Application through the New Project Wizard.
In other words: The class library is put aside for now and I'm trying to
solve this by performing tests in a clean C# Win32 app. The problem is
reproduced in this project as well (as well as in VB.NET).
This image(
http://www.inloop.se/temp/debugger.jpg) is a screenshot from that
project and as you can see the string are null even though the debugger has
stepped through the code. Another odd thing is that the debugger went into
the catch block and instantiated an empty(I guess) exception.
In the debug output window, I can see that the symbols for my application
are loaded for the exe:
'WindowsApplication3': Loaded 'C:\Documents and Settings\mikaelo\My
Documents\Visual Studio
Projects\WindowsApplication3\bin\WindowsApplication3.exe', Symbols loaded.
Yet another thing to point out is that I can debug the class library I was
working on using an ASP.NET application as an entry point. Win32 debugging
does not work but ASP.NET debugging does.
What is the difference between these two debugging methods? I can think of
stuff like they are being run as different users and different processes.
But what I don't know is what differs between the two in terms of what they
use to perform their tasks. Somehow the Win32 one has gone mad.
I don't know if it has anything to do with this, but when this first seized
working, I was using the WebClient class alot. I was also using edit and
continue as well which caused VS to hang for some reason (maybe due to open
connections or something). It was sometime during this time, this problem
occured the first time. But it would seem strange if you could break the
debugger by abusing it a bit.
Thanks!
Mikael Östberg
[quoted text, click to view] "Nick Hertl" <nhertl@gmail.com> wrote in message
news:1124832985.379439.294670@g47g2000cwa.googlegroups.com...
> This can easily happen if the source has changed since the last time
> you compiled your application.
>
> If for example you began with this:
>
> ------
> string test1;
> string test2;
>
>
>
> [some other initialization code here]
>
>
> try
> {
> }
> catch (Exception e)
> {
> Console.WriteLine(e);
> }
> -----
>
> You compile this, but then change the source to something like this
> instead and then debug without recompiling:
>
> ------
> string test1;
> string test2;
> try
> {
> }
> catch (Exception e)
> {
> Console.WriteLine(e);
> }
> -----
>
> The result is that the debugger thinks it has stepped through all that
> code that used to be there and is just reporting the line number that
> used to go with that, but since it's changed since then it no longer
> matches.
>
> Now how could this have actually happened?
>
> Usually VS will not even let you start debugging without re-compiling
> first, so chances are good that something is preventing the compile
> from completing and this is getting ignored. Maybe you have an error
> in your code or perhaps some other file has a lock on the files that
> you are trying to compile to.
>
> Another possibility is that you have set your project up as a "Retail"
> project which can make debugging very painful.
>
> What I would recommend is the following:
> Look at the files that you think you are running and check out the date
> and time they were last modified. If it seems like too far in the
> past, this is likely the problem. If it really is totally recent, then
> look for a matching file with the same name but ending in pdb instead
> of exe and see if it is also new.
> I'm guessing that you will find at least one of these files is older
> than you think it should be because it's not getting compiled correctly
> before you begin debugging.
>
> I hope that this advice helps. Please re-post if you are still having
> trouble.
>
