[Mono-list] SPAM-LOW: Re: NUnit Version - Upgrade soon?

[Gert Driesen]

> -----Original Message-----
> From: Charlie Poole [mailto:cpoole at pooleconsulting.com] 
> Sent: dinsdag 25 november 2008 20:36
> To: 'Gert Driesen'; 'Juan C. Olivares'; 'Sebastien Pouliot'
> Cc: mono-list at lists.ximian.com
> Subject: RE: [Mono-list] SPAM-LOW: Re: NUnit Version - Upgrade soon?
>
> Hi Gert, 
>
> > NUnit requires the nunit.framework assembly to be either in 
> > the GAC, or in the same directory as the test assembly.
>
> Actually, it would be more correct to say that the CLR requires
> assemblies to be installed in the GAC or in the probing path
> or the appbase/probingpath of the test assembly. NUnit would
> need to do some special tricks to force loading of the framework
> into the test domain with the test assembly.
>
> > I would like to see this changed, but Charlie (NUnit) prefers 
> > to keep things as is.
>
> I'm not very confident about special loading tricks. They can
> come back to bite you later. We've discussed this before, but
> I'll summarize for the others on the thread:
>
> 1) Conceptually, the NUnit framework is not a part of NUnit,
> it's a part of the user tests.
>
> 2) The framework doesn't execute the tests, rather the tests
> reference the framework.
>
> 3) NUnit (or if you like, the rest of NUnit) does not reference
> the framework at all. This is what makes it framework-independent.
>
> 4) NUnit can run with *any* framework that provides the same
> namespaces, classes and methods as nunit.framework.dll. For
> example, it can load tests written against the NUnitLite framework.
>
> 5) The next release of NUnit will include multiple frameworks,
> one built against the 1.1 runtime, one against the 2.0 as well
> as at least one version of NUnitLite. The following (3.0) release
> will have other alternative frameworks.
>
> It's probably not impossible to do some tricks with loading
> the framework but I'm not clear what the payback is. I've worked
> on dozens of projects using NUnit where we copied all the 
> assemlies needed into a directory before running tests. If
> the application needed (for example) a charting assembly, we 
> copied it. If a test needed nunit.framework, we copied it.
>
> This seems to be a quite normal part of the build process and
> I can only think that NOT needing to copy the nunit framework 
> would be source of confusion to developers.
>
> Of course, I understand the reason we look at this differently.
> You are viewing nunit.framework as a part of NUnit, which it
> should naturally make available in any run. Because framework-
> independence was so important, I made changes in version 2.2
> to separate the framework from the rest of NUnit and rely
> on the names of attributes rather than their type. Since then,
> new releases have worked with any version of the framework
> going back to 2.0.

I actually wanted to ship a NAnt wrapper task for nunit-console (packaged in
either the NAnt or NUnit distribution) that allows users to run unit tests
on different target frameworks.

To make things easier for users (and to avoid bug reports where users use
the wrong nunit.framework flavor with a given CLR, eg. 2.0 nunit.framework
on 1.0 CLR), I was hoping not to require them to copy the right flavor of
nunit.framework (or any other framework) in the loader path.

However, for this to work with xcopy deployment NUnit needs to fall back to
the framework that it ships with.

Automatically copying the nunit.framework to the directory containing the
test assembly is definitely not an option, as we might not even have write
access there.

Right now people use the <nunit2> task - which uses the NUnit API - and
expect it to run their tests on the current target framework, while in fact
it will always run them on the CLR in which NAnt is running.

Do you have other ideas on how we can improve the experience for users?

> > I don't think any of the other assemblies need to be in the 
> > GAC though.
>
> For testing purposes, no. If we want to allow alternate runners
> to simply find and use an existing NUnit installation, then
> either the GAC or some sort of private dynamic load mechanism
> is needed.
>
> One issue here is the fact that NUnit is cross-platform. As
> you probably know, the GAC is looked on somewhat differently
> by the MS and Mono communities. Each time I've proposed use
> of the GAC to folks using MS .NET - on the altdotnet list,
> for example - there have been lots of objections. Private
> installation seems to be preferred by that community.
>
> OTOH, Linux developers are accustomed to shared libraries
> and, because of the existence of viable package management
> systems, have not experienced "dll hell" as a result. In
> this community, use of the GAC seems like a natural 
> extension of shared libraries.
>
> Because NUnit's loading of assemblies is central to its
> purpose, I'd like to avoid having a different way to do
> it on Windows and Linux. So if it's to be in the GAC
> on one, then I think it should also be in the GAC on
> the other.
>
> I do prefer using the GAC to rolling my own loading
> mechanism, btw.

I don't think NUnit should rely on the GAC, but that doesn't mean its
assemblies cannot be installed in the GAC (when its installed through
package management systems or an installer).

Gert