Re: GCHandle exception (appdomain related?)

Hi Andres, 

> >> The plans you comment about the 3.0 releases sound really good. I 
> >> hope that you don't forget to support us the domain=none 
> users :) , 
> >> and thus prevent us to make this hack! ;)
> > 
> > There's more chance of supporting it if we have a use case 
> that makes 
> > sense. Can you explain further your situation?
> 
> Well, I guess the generic situation here is dealing with 
> Gtk#, which is not multiple-appdomain-friendly, but I'll cook 
> up a small testcase for you once I get all my problems solved.

OK, that wil help.
 
> Now I'm stuck with something that maybe has changed from 
> 2.2.0 to 2.4.7:

Well, yes. :-)

> it seems that the final reports that NUnit flushes to the 
> standard output, in 2.2.0 they got flushed when all [Test] 
> have finished, however for 2.4.7 they seem to wait until the 
> [TestFixtureTearDown] is completed, which is preventing me to 
> look at them because I may be having bug in the 
> [TestFixtureDown] method which freezes the tests.

Two main changes would affect this in the 2.4 series:

1. In order to keep output matched with test events, every
write is transformed into a TextOutput call, which is
a new method on the EventListener interface.

2. In order to isolate the runner from changes made to the
thread context, all EventListener events are placed on a queue. 
A separate thread pull them off and re-dispatches them. 

The relevant code, if you're looking at the source, is in
  EventListenerTextWriter - which is what captures the writes
  EventQueue - the queue that holds the events
  EventPump - the object that reads the queue
At one point, I used a BufferedEventListenerTextWriter class,
but had the sort of problem you're seeing, so it's no longer
used. All writes go directly to the queue and the items
are pumped as fast as the pump thread can finish the previous
event. Delays are possible because the event has to go into
the STA, so if your test uses the STA, that could be a cause
of the blocking you're seeing.

> Can we have that "feature" back or am I missing something?

So, the feature you were seeing was part of the design - and
still is. Output is supposed to pass through immediately, without
any buffering, and no flushing is needed. What I can't quite
get is why the use of the same AppDomain would change the
behavior, since everything I described above still happens
in that situation. It could be that whatever hang in your
test is the trigger for this behavior just doesn't happen
when run in the same domain.

[Just thought of something. Does your GTK stuff need to run
in the STA? Have you set up your test config accordingly?]

Some of the event pumping code was cleaned up in 2.5, but
I can't find any bugs that were being fixed. It looks as
if I was fixing some issues around stopping of the event
pump. So that's also a possibility. If you're feeling
like working on the bleeding edge, you could try the
2.5 alpha release. :-)

Charlie
> Thanks,
> 
> 	Andrés
> 
> -- 
> 
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge Build the coolest Linux based 
> applications with Moblin SDK & win great prizes Grand prize 
> is a trip for two to an Open Source event anywhere in the 
> world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Nunit-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/nunit-users
> 



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/