I'm certainly not saying drop NUnit 2.0 support in favor of 2.1 support.
I'm still asking what those short commings in the runner where. I haven't seen anything on the nunit mailing list, at least not for quite some time. We can't fix it if you won't tell us what the issues are. I'm not getting a lot of complaints on it on the nunit mailing lists. So please tell me what the issues are.
I have to admit I had an easier time with the original implementation of nunit2 support than this one. I completely admit that I made a serious error in judgement using the fork attribute. This seemed to cause quite a bit of confusion, but I very very intentionally wrote it to use TestDomain. I knew what the plans for that interface were. I also knew that the interface RemoteTestRunner was much more likely to change than TestDomain.
I'd also like to get rid of that ugly unhandled app domain unload exception that comes up when I run the nant build script. It doesn't cause the build to fail, but if you read the output it's there.
I'm currently working on making nunit 2.1 work as well as nunit 2.0. The major external feature of nunit 2.1 is the ability to pass more than one assembly into nunit. In order to take advantage of that I really think TestDomain has to go back in.
|
Hi Mike, <<A new version of NUnit is working its way toward beta. It has some features that people might want, but some of the interfaces have changed. The NUnit2TestDomain won't work since the interface to RemoteTestRunner has changed. We probably have to shift back to using NUnits TestDomain. >> Quick question here: Are you proposing wew dump NUnit 2.0 support in favor of 2.1, or keep them both? Unless we deal with this correctly, it could become a mess.... Notice: I haven't taken a look at the new version yet. I certainly hope several of the runner shortcomings have been fixed, but I'm not much hopeful. -- Tomas Restrepo [EMAIL PROTECTED] |
