debug mode for nunit-console

[Nikolai Koudelia]

Hi,

I need to debug a test but attaching a debugger to nunit-console process is problematic. I have to modify test code to wait (sleep) for 10 seconds before test execution. During those 10 sec I attach the debugger.

A much better approach would be to have a /wait or /debug switch in the nunit-console.exe which would wait for a key press (and let attach the debugger) before starting test execution.

Or maybe there is some other, better way?

Note: I can't use nunit.exe (the GUI) version because it lacks the /nothread switch which I must use.

BR,
Nikolai

[Charlie Poole]

Hi Nikolai,

The NUnit 3.0 console has a --pause option to do what you want. That
still does not solve the
problem of possibly needing to attach to the nunit-agent process,
where one is used, but
I'm trying various approaches, including passing the same option on to
the agent. Having
two different options seems too confusing.

For now, one possibility is to use Visual Studio or any other IDE to
run nunit-console under
the debugger in the first place.

The other choice is to put a call to
System.Diagnostics.Debugger.Break() in your tests,
but that requires editing and recompiling.

As another matter, I'd like to understand why you need the /nothread
option. It has been
scheduled for removal in NUnit 3.0 and so far nobody has complained.

Charlie

Charlie

> --
> You received this message because you are subscribed to the Google Groups
> "NUnit-Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nunit-discus...@googlegroups.com.
> To post to this group, send email to nunit-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/nunit-discuss.
> For more options, visit https://groups.google.com/groups/opt_out.

[Nikolai Koudelia]

Hi Charlie,

thanks for the tip about System.Diagnostics.Debugger.Break(), didn't know about that.

I'm not sure about the details, but the SUT I'm dealing with (a GUI application) runs both managed and unmanaged code which requires the /nothread and /domain:none flags.

-Nikolai

[Charlie Poole]

What happens if you leave off /nothread? Is there some sort of exception?

Depending on the version you use, /nothread may not be doing much for
you any more.

Charlie

[Tyrel Alastair Hunter]

Charlie, I would not be surprised if the reason Nikolai  is needing the /nothread and /domain:none flag is for the same reason that my work switched to using nunitlite instead of the full features nunit. Maybe Nikolai can answer if the unmanaged code ever has a managed function passed in as a parameter to some function which the unmanaged code then executes at a later time. For example some unmanaged function that performs a task and then invokes a managed callback on completion. If so Nikolai can you please give me more details on the error you recieve when running without those flags. I am interested to find if we are not the only ones having this issue? Thanks

—
Sent from Mailbox for iPhone

[Nikolai Koudelia]

Unfortunately I don't have access to the unmanaged code and thus I can't say for sure what's going on there. When I remove either /nothread or both /nothread and /domain:none parameters, a function call to the unmanaged code (which doesn't take any arguments) never returns. It doesn't throw any exceptions, it just hangs. I'll try to find out what is happening in the unmanaged code and if I can reproduce it, I'll show the code here. The NUnit version in use is quite old too, 2.5.7. I'll try running the same tests with the newest version.

-Nikolai

[Charlie Poole]

HI Nikolai,

That would be helpful. If there is some way to make the /nothread
option unnecessary in future releases, I prefer to do that.

One reason is this: In the past, NUnit did not run tests on a separate
thread. When we introduced use of a separate test thread, we added the
/nothread option to support it. At the present time, I believe we
always use a separate thread, even when /nothread is specified, so the
option is misleading at best.

What I'm not sure of is how the combination of /domain:none and
/nothread changes things. That will take some tracing in the code
because they are both little-used options that I haven't looked at for
a while. As Tyrel points out, using NUnitLite is quite similar to
having this combination of options in NUnit, so we may be on to
something.

Charlie

[Charlie Poole]

Hi Tyrel,

If you have the time, it would be great if you could come up with a
test solution having a set of examples of calling unmanaged code.
Ideally, it would show what works and what doesn't. One problem with
this whole issue is that most people having trouble with unmanaged
code have not been able to provide examples, not having access to the
source.

Charlie

[Nikolai Koudelia]

I'm not sure, but I think my issue is somehow related to this topic: http://stackoverflow.com/questions/127188/could-you-explain-sta-and-mta

The following check in the test code normally prevents it from going into the unmanaged code if ApartmentState != STA:

Assert.True(Thread.GetApartmentState == ApartmentState.STA, "ApartmentState of the tread must be STA");

The /nothread flag seems to set ApartmentState to STA, otherwise it's MTA. And when it's MTA, the unmanaged code (UI component which most likely includes some COM objects) gets stuck.

-Nikolai

[Nikolai Koudelia]

> The /nothread flag seems to set ApartmentState to STA

Well, actually it doesn't do that on my home machine - the ApartmentState is MTA regardless of the nunit-console flags. I'll dig into this deeper when I get back to work...

-Nikolai

[Tyrel Alastair Hunter]

I am not sure this is the same issue that we had Charlie as we were getting errors trying to marshal memory across app domains during native code tried to call a managed c++ function. However even though it's not entirely the same issue there may be a common cause. 

—

Sent from Mailbox for iPhone

[Tyrel Alastair Hunter]

I could attempt to come up with an example for our issue I have an idea what causes it however I do not have the source for it either someone in Germany does. But I believe that I should be able to create a solution that shows what I now works with native c++ interop libraries and I'll try to produce a sample function that demonstrates the failure as well.

—

Sent from Mailbox for iPhone

[Tyrel Alastair Hunter]

In addition I think we would need two samples as I am currently aware of 2 ways to have native interop in c# the first I believe to be fully functional but untested. Is to use a VC++ wrapper around the native code. The second requires compiling a native c++ dll with the CLI flag

—
Sent from Mailbox for iPhone

[purnank h g]

On Tue, Oct 1, 2013 at 8:32 PM, Charlie Poole <nuni...@gmail.com> wrote:

Hi Tyrel,

If you have the time, it would be great if you could come up with a
test solution having a set of examples of calling unmanaged code.
Ideally, it would show what works and what doesn't. One problem with
this whole issue is that most people having trouble with unmanaged
code have not been able to provide examples, not having access to the
source.

Charlie

May be you can use https://bitbucket.org/purnank/teststoppingnunit as the starting point to write a similar managed + unmanaged code.

 

>>> On Mon, Sep 30, 2013 at 12:34 AM, Nikolai Koudelia <niko...@gmail.com>
>>> wrote:
>>> > Hi,
>>> >
>>> > I need to debug a test but attaching a debugger to nunit-console
>>> > process is
>>> > problematic. I have to modify test code to wait (sleep) for 10 seconds
>>> > before test execution. During those 10 sec I attach the debugger.
>>> >
>>> > A much better approach would be to have a /wait or /debug switch in the
>>> > nunit-console.exe which would wait for a key press (and let attach the
>>> > debugger) before starting test execution.
>>> >
>>> > Or maybe there is some other, better way?
>>> >
>>> > Note: I can't use nunit.exe (the GUI) version because it lacks the
>>> > /nothread
>>> > switch which I must use.
>>> >
>>> > BR,
>>> > Nikolai
>>> > 

Nikolai, would it be possible for you to invoke "nunit-console" as the primary application to be debugged/invoked to visual studio and pass the Managed DLL and other flags like /nothread /domain:none as command line parameter to nunit-console?

BR,

Purnank

 

[Charlie Poole]

NUnit itself runs on an STA thread. Once it's running, you naturally
can't change the ApartmentState.

Looking at the NUnit 2.6.2 code, I found that the /apartment option on
the command line is ignored unless the ThreadedTestRunner is used.

Of course, this makes sense: You can only set the ApartmentState on an
uninitialized thread. However, the console help seems to indicate that
the option will work in any case. It would probably be more logical to
force use of the ThreadedTestRunner if you specify ApartmentState on
the command line.

By specifying /nothread, you are running on the same principal thread
that starts NUnit itself and by specifying /domain:none you are
running in the same AppDomain. If all you want is to be running in the
STA, you may try specifying /apartment:STA on the command line
instead. Try it with and without /domain:none.

These options are entirely too confusing!

Charlie

Charlie

[Charlie Poole]

Hi Purnank,

Thanks for the example. In NUnit 2.6.2 I added code to deal with
several cases where a thread was not terminating when cancelled. Have
you run this example with 2.6.2?

Charlie

[Nikolai Koudelia]

Hi Charlie,

> ... you may try specifying /apartment:STA on the command line

That option was not available in 2.5.7 which I have to stick to for now (it's an in-house customized version of NUnit) but there is the RequestSTA attribute (http://www.nunit.org/index.php?p=requiresSTA&r=2.5) which does the job.

So, yes, I didn't need the /nothread flag after all.

I need the /domain:none though, because otherwise I get an exception similar to this:

Unhandled Exception: System.ArgumentException: Cannot pass a GCHandle across AppDomains.
Parameter name: handle
   at System.Runtime.InteropServices.GCHandle.InternalCheckDomain(IntPtr handle)
   at System.Runtime.InteropServices.GCHandle..ctor(IntPtr handle)
   at System.Runtime.InteropServices.GCHandle.FromIntPtr(IntPtr value)
   at gcroot<NS::ISomeEventListener ^>.->(gcroot<NS::ISomeEventListener ^>* ) in c:\program files (x86)\microsoft visual studio 10.0\vc\include\msclr\gcroot.h:line 127
   at NS::ManagedEventListener.OnSomeEvent(ManagedEventListener* ) in c:\src\...\SomeManagedCPP.cpp:line 37

This appears to be exactly the same situation ialastairhunter described earlier - unmanaged code tries to call a callback function from the managed side.

Is there a way to use nunit.exe GUI (which lacks the /domain option) for running tests in primary domain like nunit-console does?

-Nikolai

[Nikolai Koudelia]

> Nikolai, would it be possible for you to invoke "nunit-console" as the primary application to be debugged/invoked to visual studio and pass the Managed DLL and other flags like /nothread /domain:none as command line parameter to nunit-console?

Yes, that's how I run tests now, but it's a bit invonvenient because the test name needs to be changed each time in the project properties.

-Nikolai

[Charlie Poole]

In theory, it would be possible to run tests in the primary domain
using the gui, but it would require copying all the nunit files as
well as your own into the same directory structure. That's not very
practical, of course. A more promising approach would be to allow the
nunit-agent to run tests in its primary domain, which is where I'd
like to go in NUnit 3.0.

Charlie

[Tyrel Alastair Hunter]

This error appears to be the exact same issue we were having prior to switching to nunitlite Charlie. I will work on getting some sample solutions created so that we can more easily develop a fix for this.

—

Sent from Mailbox for iPhone

[Charlie Poole]

Great!

[Nikolai Koudelia]

That sounds great! Thank you all for your support.

You received this message because you are subscribed to a topic in the Google Groups "NUnit-Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nunit-discuss/44JWWxJ8DM0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nunit-discus...@googlegroups.com.