RE: NUnit Version Numbering

Hi Matt,

Thanks for chiming in. Comments inline.

Charlie

> -----Original Message-----
> From: Matt Hargett [mailto:matt@xxxxxxx]
> Sent: Thursday, December 08, 2005 3:41 AM
> To: Kamil Skalski
> Cc: Charlie Poole; nunit-developer@xxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [nunit-developer] NUnit Version Numbering
> 
> Kamil Skalski wrote:
> >> Because I knew that this might cause special problems with mono, I
> posted on
> >> the mono-devel list, as well as here. So far, there has been no
> feedback. I
> >> stay in touch with a number of the Mono developers and I'll adjust what
> I'm
> >> doing when I have better info about what Mono needs.
> >
> > Mono developers seem to use mostly the 1.1 profile and didn't take the
> > problem too seriously so far. But from time to time people got into
> > problem. Basically it is caused by the fact that mono installs
> > nunit.*.dll into the GAC and the current versioning schema do not
> > allow using separate GAC entries for 1.1 and 2.0 compiled nunit
> > assemblies.
> >
> > I like your idea of removing nunit dll from the gac at all, of course
> > if everything would still work fine.
> >
> > Currently there is a mono bug for the issue and I hope it will
> > eventually be resolved and things would work with mono:
> > http://bugzilla.ximian.com/show_bug.cgi?id=76928
> 
> Sorry I didn't chime in sooner -- this problem (I wrote the mono bug you
> are referencing) would be fixed by having a different build identifier
> for .NET 2.0 versions of NUnit. You mentioned the different version in
> the bug, but another possibility would be to name things differently.
> That is, the 1.x build remains nunit-* and the 2.x build would be nunit2-
> *.

What about the possiblility of simply using local assemblies for all but the
initial exe? Even that could be eliminated by the use of a script.

> I think mono needs to continue "shipping" with nunit so that users can
> run mono's own unit tests to test the class libraries and whatnot. Also,
> it makes for a nice OOTB experience IMO :)

I can see that, but with a few exceptions...
1. My copy of mono 1.1.10 - the windows install - comes with nunit but
without the tests - at least I can't find them, which amounts to the same
thing. :-)

2. That same copy comes with a 2.0 profile build of nunit-console.exe, but
not of any other assemblies.

3. We need to have a way to install multiple copies of NUnit, if we are ever
to have a set of developers who work on NUnit on a mono platform. Having
mono itself "decide" which version of nunit gets priority is a bit of an
obstacle. Imagine that I were to switch from MS .Net to mono as my primary
dev platform. I'd need to jump between all releases of NUnit that are
currently buggable: 2.2, 2.2.1, 2.2.3, 2.2.3, 2.2.4(in release) and the
2.3.x development mainline. This would be easier if the 2.2 version that
comes with mono were either hidden, or installed as just another package
rather than seeming to be a part of mono.

4. Right now, if I were to put together a package to install NUnit 2.2.4 on
mono, I would have to replace the files in lib/mono/1.0, which doesn't seem
like a good idea. I realize this could just be a lack of understanding on my
part, so let me know if I've got it wrong.

5. I'm not clear why installing nunit with mono needs to imply putting all
the assemblies in the gac. 

> Right now for them to run their .NET 2.x assembly tests, they have a
> .NET 2.x-compiled nunit binary in their source tree that does not get
> installed. I was able to "workaround" in a real PIA fashion to get the
> above bug to not show up.

PIA?


Charlie

> Anyways,
> there's my 2p :)




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click