Hi Gerry,

> Yes, this seems like either:
> 1. We are missing something, or
> 2. A mistake.
>
> Tomas can you post (maybe just send the post you sent here) to them?
> You seem to have the most experience with the issue.

Done. I'm waiting to hear on more information. From what I can gather now,
it seems now you must always set up a new properly configured appdomain for
the tests.

I've digged into NUnit's implementation more, and it seems that a ton of it
expects to be able to load the test dlls using standard assembly loading
rules that apply to loads using unqualified assembly names. This is exactly
the crux of the problem right now.

It also seems that the current code in nunit would inhibit the use of
certain features we took for granted in nant with nunit 1.0, like having the
nant/nunit dlls load automatically from nant's directory (which doesn't seem
to work now with 2.0... at least in the cases I'm trying), and some other
functionality that had been added to nant, such as the ability to specify
which config file to load.

So, right now, with what little I know about the nunit implementation, I
can't see any other way to regain all this without reimplemeting pretty much
everything from TestSuiteBuilder upwards (basically that, plus
RemoteTestRunner and TestDomain). It's not really that hard, but it is very
annoying...

I'm still holding out for a better way to do this, but as thing stands,
nantcontrib is right now stuck, testwise, and at least I won't be able to
use nunit 2.0 for my largest project :(

--
Tomas Restrepo
[EMAIL PROTECTED]



-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
_______________________________________________
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

Reply via email to