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

[Charlie Poole]

Hi Gert, 

<snipped my earlier note/>

> 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.

It's true that a process command-line interface is an easy
way to provide compatibility. But nunit-console is designed
for direct user usage and could easily change to invalidate
what you want to do.

Alternatively, nunit-agent is intended for running tests
but has the disadvantage that it communicates via remoting,
requiring at least one assembly in common between it and
the client.

So maybe a special-purpose runner that functions logically
the way nunit-console does is a better approach.

Still, I haven't yet given up on a client/server approach.

> 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.

Hmmm... it seems as if such a problem should only impact users
who already use multiple versions of NUnit in their application.
And they have to deal with it in any case.

My assumption is that NUnit would not be installed on a 
build machine in such a case anyway, but that the proper
assemblies would be included in the tree. I agree that
their will be errors if the user has to go out to an
install directory and find assemblies.

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

NUnit could fall back on the framework it shipped with if it
actually used the framework. However, it doesn't. NUnit has
no reference to the framework. It executes the user tests
directly and those tests execute framework code.

We could modify NUnit, of course, to know about it's
framework, but that would eliminate the ability to run
against more than one framework.

AFAIK, NUnit is not xcopy-deployed under Mono. And its
not xcopy-deployed by default under Windows. The Mono
install has NUnit in it's GAC - if I understand correctly.
The Windows installer doesn't use the GAC, but does other
things besides just copying files. OTOH, NUnit can be
xcopy-deployed, as is now done by teams that copy the 
binaries into their tree.

I'm feeling a little fuzzy about the benefits you see
from xcopy deployment.

> 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.

Agreed. And even if we did have write access, copying files
around without being asked is pretty intrusive.

> 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.

That's because the current API doesn't allow you to specify
what framework to use. But the new API does.

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

Under the current API, you would have to locate the correct 
NUnit assemblies and make use of them. I believe that's what
is currently done in tasks like the csc task. Of course, it's
possible that the user may have installed only the 2.0 version
of NUnit, in which case it's just not possible to run tests
in 1.0.

This is fixed in 2.5, since you get both builds of NUnit in 
one installation package.

<snip/>
> > 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).

So you're suggesting that NUnit should detect whether certain
assemblies are installed in the GAC and act differently?

What rules do you think it should follow in that case?

Charlie
 
> Gert
> 
> _______________________________________________
> Mono-list maillist  -  Mono-list at lists.ximian.com 
> http://lists.ximian.com/mailman/listinfo/mono-list
>