views:

50

answers:

2

The answer to this has got to be simple, but I sure don't see it.

I'm working on an MVC2 project under VS2010, with Unit tests written in NUnit.

I debug the tests (and code) by starting the NUnit GUI, then clicking Debug -> Attach To Process in VS, and attaching to nunit-agent.

This has all worked fine for some time.

I added one additional test for a bug that I discovered this morning, and suddenly, my breakpoints are not being hit. NUnit just runs merrily along and says the test passes (which it shouldn't, since I haven't fixed the bug yet), without ever stopping at the breakpoint I have set on the very first executable line in the test method.

I've looked at everything I can think of, including rebooting the machine, and I can't figure out what has changed. (FWIW, the test project is configured to run under .NET 3.5, and I'm running NUnit 2.5.4. I have added the 4.0 "supportedRuntime" flag and "loadFromRemoteResources" flag to the section of nunit.exe.config, and I have also tried attaching to nunit.exe instead of nunit-agent.exe. Note that I am NOT getting the disabled breakpoint buttons with the "source code cannot be loaded" messages. The breakpoints are the standard red ball, they just never get hit.)

A: 

Try attaching to the nunit-agent.exe process. That worked for me.

Nick DeVore
Sorry, answered before I read all the way to the bottom. AFAIK, you're doing everything you should.
Nick DeVore
A: 

The answer was indeed simple.

Somewhere along the line, I had been using VS2010 to debug Script code by attaching to the browser. When you attach to a process in the debugger, you have to tell it what kind of code you are debugging, and debugging script code is incompatible with debugging managed code, so it turns off Managed code. Apparently VS remembers your last selection.

So when I attempted to attach to N-Unit, it was selecting Script as the type of code that I wanted to debug, and I didn't notice. All I had to do was select the drop down box in the "Attach to process" dialog box, and check managed code.

Thanks to Paul Laudeman in his CodeBetter Blog

Dave Hanna