Debugging NUnit tests under Visual Studio 2010

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.

Edit:

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>
This sets NUnit to run under the 4.0 CLR.
According to this page you should also add this line under the runtime element:
<loadFromRemoteSources enabled=”true” />
This allows libraries downloaded from a remote site (such as a website) to be loaded with full trust.  I’m not sure why this would be necessary and indeed, my application debugged NUnit just fine without it.  However, if you have problems, you might want to give it a try.
Note that the link given above gives the version number to enter as v4.0.20506 whilst here I’ve said 4.0.30319.  The former is for the .Net 4 beta, whilst the latter is the RTM version.  A good list of version numbers can be found here.
Hope that helps!
Advertisements

21 thoughts on “Debugging NUnit tests under Visual Studio 2010

  1. That’s because nunit.exe runs with .NET2 and thus loads the test assembly (referenceing .NET4) in the nunit-agent child process.
    If you force nunit.exe to load .NET4 (by including in the nunit.exe.config, things will behave as before.

      • Frater,

        Actually, NUnit without the config change to startup will always use .Net 2.0 and that is the reason that when you compile the test class with VS 2010 and 4.0 compiler, NUnit does not recognize the tests in the assembly because NUnit is still running under .Net 2.0. It is by design that it was conceived that NUnit 2.x.x. should not recognise .Net 4.0 and NUnit 3.0 onwards will run under .Net 4.0 without any need for config changes.

        As far as I know, it has got nothing to do with the agent.exe.

        Regards,

        Jv

  2. Thanks for the info, I was starting to go through the process of attaching the debugger manually and going to work out a script or something – this appears to have done the trick.

  3. Ah, thanks for this. Initially, this solution didn’t work for me because I copy and pasted the code snippets and the nice looking quote characters weren’t parsed correctly in NUnit. (When I ran I got a File Not Found exception that nunit.core couldn’t be found.) Finally, I noticed that my editor had highlighted the quoted strings differently than quoted strings in the rest of config file.

    BTW, I’m using this in nunit-console.exe.config since I prefer the console when running directly from VS.

  4. Note that ”4.0.30319″ should read ”v4.0.30319″ (note the leading ‘v’).

    Your example configuration did not work for me without this missing character.

  5. Pingback: 关于nunit调试VS2010中的4.0程序集的问题 | 逸天博客

  6. Thanks a lot! If anyone can’t get it working make sure you put the code snippet inside the configuration element not after the closing tag.

  7. Pingback: VS2010下使用NUnit 无法进行调试的问题 at 343校舍

  8. Pingback: VS2010下使用NUnit 无法进行调试的问题 | 343校舍

  9. Pingback: VS2010下使用NUnit 无法进行调试的问题 | 343校舍

  10. Please add
    supportedRuntime version=”4.0″ under startup useLegacyV2RuntimeActivationPolicy=”true”
    in configuration file if you want to enable debugging by hitting F5 in Visual Studio 2010

  11. Also, be sure when you are editing the .config file that you are editing the correct file! So in my case, nunit-x86.exe.config. Editing nunit.exe.config was ineffective, since I’m running the x86 version. Thanks again!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s