2

Apologies for the title, but I really am having difficulty even defining what's going on here.

I have a program with a line

long svnSuccess = SVNCommands.GetSVNHeadRevNo(svnLocation);

SVNCommands is a static class.

If I put a breakpoint on the line above, and then F11 (step into) to watch the execution of the code in SVNCommands it just... nothing. Behaviour is like an infinite loop. The program doesn't crash in any way. It just stops proceeding. VS doesn't take me to SVNCommands.GetHSVNHeadRevNo. I even have breakpoints at the start of that function (just to prove it's not getting there without realising) and they're not reached.

Any ideas as to what might be happening here?

technorabble
  • 391
  • 7
  • 16
  • You might want to manually delete everything in the `\bin` folder and try again? Sometimes visual studio can't overwrite the .dll because it's locked by the hosting process. It's basically stepping through an old version of the assembly, not the one you have there. – Paul Aldred-Bann Mar 31 '14 at 15:03
  • SVN was originally written in native code so it is not unusual that step-into is not showing you anything. Having the method block on an unresponsive server or a COM apartment transition with the thread that owns the COM object being blocked is not unusual either. Debug + Break All ought to give you control back. – Hans Passant Mar 31 '14 at 15:11

2 Answers2

0

Try adding System.Diagnostics.Debugger.Break() in GetSVNHeadRevNo and run the program without debugging. It should ask you if you want to debug and hopefully hit the code. Im not sure why your debugger isn't working. If SVNCommands was in an assembly that didn't match your debug file, it would give you a warning.

If that doesn't work, try deleting your Visual Studio Cache. To my understanding, that solves a lot of unexplained problems. Try using the answer from How do you clear your Visual Studio cache on Windows Vista?

Community
  • 1
  • 1
bsayegh
  • 990
  • 6
  • 17
0

A bit of an odd fix for me herre - probably not often relevant to others.

Dev machines are 64 bit, but the end user machine is 32 bit.

That's generally fine, but we only have the 32 bit SharpSVN dlls. Everything worked as intended until we jumped into solution settings and changed target platform from "x86" to "any CPU". Then, in testing on the 64 bit dev machines, as soon as entered the function, which currently looks like this:

public static long GetSVNHeadRevNo(string svnLocation)
    {
        using (SvnClient client = new SvnClient())
        {
            setupAuthentication(client);
            SvnInfoEventArgs info = null;
            Uri repos = new Uri(svnLocation);

            try
            {
                client.GetInfo(repos, out info);
            }
            catch (Exception ex)
            {
            }

            return info.Revision;
        }            
    }

I guess the program tried to suck in the required DLLs and then had a (quiet) fit.

Changing target platform back to x86 has resolved all issues. Thank you to everyone who helped.

technorabble
  • 391
  • 7
  • 16