NUnit 2.2 problem with VS 2005

I finally decided to start playing with the beta of VS 2005. First stop: Get some existing code working. So I take an API that I wrote, complete with unit tests and decide to give it a whirl. First NUnit coughs up a bad image format exception. This was quicky remedied by a Google search and a tript to James Newkirk's blog and I thought I was home free. NUNit GUI comes up, I pick my dll and all the tests appear in NUnit's treeview. As soon as I try to run a test I get this:

                 "No source code available for the current location."

Illegal cross-thread operation: Control 'suiteName' accessed from a thread other than the thread it was created on.
Stack trace where the illegal operation occurred was:

at System.Windows.Forms.Control.get_Handle()
at System.Windows.Forms.Control.get_WindowText()
at System.Windows.Forms.Control.get_Text()
at System.Windows.Forms.Label.get_Text()
at System.Windows.Forms.Control.set_Text(String)
at System.Windows.Forms.Label.set_Text(String)
at NUnit.Gui.NUnitForm.OnRunStarting(Object, TestEventArgs)
at NUnit.Core.TestEventHandler.Invoke(Object, TestEventArgs)
at NUnit.Core.TestEventDispatcher.Fire(TestEventHandler, TestEventArgs)
at NUnit.Core.TestEventDispatcher.FireRunStarting(Test[], Int32)
at NUnit.Util.TestLoader.NUnit.Core.EventListener.RunStarted(Test[])
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr, Object[], Object, Int32, Boolean, Object[]&)
at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle, Object[], Object, Int32, Boolean, Object[]&)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage, Int32, Boolean)
at System.Runtime...."

I can't set a break point because this happens before NUnit runs the test so it never gets into the code. I know I have the source to NUnit but I'm not that adventurous to play around with that and VS 2005 - yet. If anyone has seen this and solved the problem please let me know. I am dead in the water without NUnit. I refuse to test any other way. Maybe I am just spoiled!




  • Even in 1.x you were never supposed to call UI component methods from threads other than the one that created the component, but you never got an exception if you tried. Now you do.

    The only way around is to actually fix the code so that you're not doing that anymore. If you don't mind fixing the nunit source, you can search for the error message on google and there's a couple of work-arounds for it that'll get you going quickly (short of a re-archtitecture to properly separate UI from logic). Things like using the "Invoke" pattern.

    Now, assuming modifying the source is out of the question for you, the only other option is to use the nunit-console.exe interface to run your tests from the command-line.

  • Setup NUnit 2.2 to run with .NET Framework 2.0

    NUnit 2.2 has been released.

    If you plan to use it with Visual Studio 2005 beta 1, <supportedRuntime version="v2.0.40607" /> in the <startup> section of the config files (nunit-gui.exe.config and nunit-console.exe.config) must appear in first position.

    Happy testing.

    posted on Friday, October

  • zhangyi

    I tried that before. Its in the link I inserted to Jame's NewKirk's blog. It doesn't help. I emailed James and he said that he heard of this problem that some people are having.

    Thanks anyway!

  • FWIW, I'm having the same problem here. My components are entirely non-visual (System.Net utility), so I'm led to thinking that the WinForms controls mentioned are those in the NUnit GUI itself... Even the most trivial test code is causing this problem.

  • Though, BTW, an OK work-around is just not to launch NUnit-GUI as the startup process. I've found it tolerable to build and then run NUnit stand-alone, loading the recently compiled assembly, though a step-through debug is not very convenient any more.

  • quite interesting post. I would love to follow you on twitter. By the way, did anyone hear that some chinese hacker had busted twitter yesterday again.

Comments have been disabled for this content.