Tuesday, August 31, 2004

VS2005 Beta1 - Source doesn't match IL while stepping through DLL

I am having the weirdest problem. I have a unit test .EXE which exercises my code which lives in a .DLL assembly. However, the code that the debugger is stepping through doesn't match what's actually happening.

For example, say I have this:

1: public bool Load (XPathDocument doc)

2: {
3: using (new LogIndent (log.Info, "Load"))
4: {
5: if (doc == null)
6: {
7: log.Warn ("doc is null -- nothing to load");
8: return;
9: }
10:
11: if (log.IsDebugEnabled)
12: log.Debug ("doc=" + doc);
13:
14: try
15: {
16: XPathNavigator nav = doc.CreateNavigator ();
17: XPathNodeIterator iter = nav.Select ("[snip]");
18: if (iter != null)
19: {
20: while (iter.MoveNext())
21: {
22: Dump (iter.Current);
23:
24: string flowName;
25: flowName = iter.Current.GetAttribute (
26: "Name",
27: iter.Current.NamespaceURI);


I have a break point on line 3 which the debugger drops me off at. At each step I'm hitting F11 - Step Into. Here is what I see:

3: using (new LogIndent (log.Info, "Load"))
7: log.Warn ("doc is null -- nothing to load");

  • Note that I should have stepped into the LogIndent constructor since the code exists in this assembly.

  • Plus, I shouldn't have jumped over the if

  • Also, I shouldn't have stepped into this if at all since doc is not null (I checked it in the calling application.)

  • 11:    if (log.IsDebugEnabled)

    Now when I step into I'm in the constructor for LogIndent that I should've hit first!?! If I continue a bit further:
    12:      log.Debug ("doc=" + doc);
    
    22: Dump (iter.Current);
    25: flowName = iter.Current.GetAttribute (

    Here again
  • I should have stepped into log.Debug

  • I should have hit the XPathNavigator, XPathNodeIterator, if and while statements

  • I should have stepped into Dump

  • to top it off, stepping into GetAttribute drops me into log.Warn with the message "doc is null -- nothing to load" from line 7

  • However, if I switch the assembly to an .EXE then everything behaves normally.

    Is it me? Should I submit this to LadyBug? Ugh.

    [Listening to: Eminem - Amityville]

    4 comments:

    Anonymous said...

    If you converted a assembly project into a .exe project, make sure to delete the old .dll file (and vice-versa) otherwize you will run into this kind of weird behavior.

    Jonathan de Halleux

    BigEasy said...

    I've fallen for that a few times, but when I first noticed the creative debugging I was still using the dll, no exe around. I did rebuild (after deleting the bin and obj directories.)

    I checked that there wasn't a copy of my stuff in the GAC too.

    I even built a new project from scratch, copying my source files in one by one until it compiled and it still happened.

    I have weeded the test case down to a fairly simple set of code which I've submitted to LadyBug.

    The lack of reliable debugger support got me off my butt to figure out why I couldn't get log4net working in an MbUnit test case (initializing in main instead in the "new" AppDomain)

    Anonymous said...

    A 'Clean' and then a 'Make' should resolve this problem (at least it has for me). You can also click on the little exclamation point and follow the instructions to resolve the issue.

    Wally

    BigEasy said...

    I wish that worked. I tried the complete rebuild -- even deleting the bin and obj directories completely.

    Nothing in the GAC. No copies of my .dll anywhere.

    I even started a new project from scratch and copied the code in bit by bit, still no luck.

    I have entered the issue into LadyBugThanks for the help.