Re: How do addon writers deal with NUnit versions?

Hi Stefan,

The problem with versions is a tough one. In theory, you should
use only the nunit.core.interfaces assembly, but almost nobody
does that, since it seems much simpler to inherit from the
implementation classes in nunit.core itself. Anyway, the
interfaces assembly has had a few changes itself, so that's
no help.

Most addins are simply distributed with and for a particular
version of NUnit. I published a nant script to make this
easier mechanically, but of course your addin has to be written
to work with various versions.

This is a problem that we really need to solve in the future.
I'm afraid I've given up on it in the 2.x series. Since 3.0
will use a more mature addin structure, one which supports
versioning, among other things, that's where I expect to fix
this.

In the meantime, the following steps may make it easier:

1) Use as little as possible out of nunit. Especially, avoid
use of internal classes, which may change. Ideally, use only
nunit.core.interfaces.

2) Use or modify my nant script (http://nunit.org/?p=addins) to
do your build. It can run against various installed versions
of NUnit and produce addins that will work with them.

3) I'm hoping to make 2.5 at least a little better than 2.4 with
regard to addins. Try it while it's in alpha and beta and join
the nunit-developer list to give feedback about some of the
changes - yes there are changes. :-)

Charlie

PS: Something to discuss on the developer list, if you are
interested, is whether we might want to bundle xmlunit with
nunit.

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf 
> Of Stefan Bodewig
> Sent: Friday, May 30, 2008 2:37 PM
> To: [email protected]
> Subject: [Nunit-users] How do addon writers deal with NUnit versions?
> 
> Hi,
> 
> about eighteen months ago I've taken over the maintenance of 
> XMLUnit[1], which provides JUnit and NUnit extensions to test 
> XML.  In the beginning I focused on the Java part since this 
> was where most of the only bug reports and enhancement 
> requests existed (and because unlike the .NET version I used 
> the Java version myself).
> 
> A few months ago I did a maintenance release of XMLUnit.NET 
> which I compiled against NUnit 2.4.6 (since that was the 
> latest release back then).  As far as I know this means that 
> people using the XMLUnit.NET binary can't use any other 
> version of nunit.framework.dll (since this is strongly named) 
> - if anybody can correct me here, I'll be happy[2].
> 
> Prior to that release XMLUnit.NET had been compiled against 
> much older versions of NUnit (before the DLL has been 
> strongly named) and things just worked.
> 
> I certainly don't want to track NUnit releases with new 
> releases of XMLUnit, and I guess other addons are in a 
> similar situation.  How do you deal with this?  Tell your 
> users to rebuild from source (this is what I advised the bug 
> reporter to do) or is there anything else I could do?
> 
> Cheers
> 
>         Stefan
> 
> [1] http://xmlunit.sf.net/
> 
> [2] I've tried some tricks with binding redirects but they 
> don't seem to work when the Tests.*dll*.config file is used.
> 
> --
> http://stefan.samaflost.de/
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft Defy all 
> challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Nunit-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/nunit-users
> 



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/