Upgrading to a new version of a development framework always holds some little surprises and gotcha’s, no matter how careful you are. I found one of these the other day during the transition of some of my projects from .Net 3.5, and VS2008, to the new Visual Studio 2010 and .Net 4.0. When I initially upgraded I ran all my unit tests to ensure they worked, and they do – the new version of NUnit supports .Net 4 already which is great news.
I didn’t play around with it too much after that as I had some problems with the Moq mocking framework running in VS2010 (more on that in a post to come), however when I did find the time to make some modifications to the tests and check them I noticed something very strange – I could no longer debug my tests. They ran fine, but in the debugger I was greeted with an old friend of anyone who has done significant debugging in Visual Studio over the last ten years – Breakpoint will never be reached, no symbols loaded.
I played around for a while and eventually found the problem. Traditionally debugging NUnit in Visual Studio has been done in one of two ways. First, you can attach the debugger to the NUnit gui manually after launching it, or you can set up the debugger to launch NUnit as an external program to launch on build (so you can F5 it!). The second method is the one I usually prefer, but unfortunately we can no longer use -either- of these methods.
I’m not sure what has caused this issue but in order to debug NUnit tests in visual studio now you need to manually attach the debugger, as above, but instead of attaching to the NUnit process you need to attach it to the NUnit-Agent process. This causes problems for people, like myself, who like to hook up NUnit debugging to the F5 key as that will attach you to the loaded program, in this case NUnit, not to the agent process.
Seems that for now the only method is manual attachment. Hopefully this will be changed back in a future version, though it may be some time.
Thanks the Klaus for pointing out a better workaround below!
Apparently the real issue is that NUnit loads up in .Net 2.0 and then has to load up the modules in 4.0, so does so under the agent process. (Though why it didn’t have to do this for 3.5 is not clear). The solution is to force NUnit to run under 4.0 itself. This can be done with the following addition to the NUnit.exe.config file.
First, directly under the configuration element, add these lines:
<startup><requiredRuntime version=”v4.0.30319″ /></startup>
<loadFromRemoteSources enabled=”true” />