nunit-dev team mailing list archive

["Charlie Poole" <charlie@xxxxxxxxx>]

Hi Jamie, 

> I think your points pretty much cover it.
> 
> > 2. User must copy the framework to the output directory if 
> not using 
> > the GAC.
> >
> Unless we ensure that it's installed in the Mono GAC as well, 
> this is an extra thing that every Mono user will need to 
> remember. A potential issue with the Mono GAC is that there's 
> a GAC per Mono version. If someone installs a new Mono 
> version, the 'nunit.framework' won't be in the GAC. This will 
> lead to inconsistent behaviour between machines.

I'll bring this to the mono-devel list. In previous discussions
with Miguel, he has been arguing for putting things like the
nunit framework in the GAC - and I've been arguing on your
side of it. :-)

But you're right, and I just ran into this problem when I 
wanted to test smokey. It wouldn't run on Mono 2.4.2, because
it used a different version of cecil, so I had to go back to
Mono 2.4.
 
> I think this is a pretty serious con for Mono users. What 
> pros are there for putting the framework in the GAC?

As nunit.framework is currently written, probably none.

I guess I'm looking ahead a month or two to the point where
we have the test loading and running functionality from core
in the framework as well. Runners will need to find the right
framework. However, I can see now that I'm getting ahead of
myself. Let's leave the option in Andreas' install program
and experiment with it as needed rather than trying to decide
on an a priori basis. Does that make sense?

Charlie

> Regards,
> Jamie.
> 
> --
> http://www.testdriven.net
> http://twitter.com/jcansdale
> http://weblogs.asp.net/nunitaddin
> 
> 
> On Fri, Jul 31, 2009 at 10:29 PM, Charlie 
> Poole<charlie@xxxxxxxxx> wrote:
> > Hi Jamie,
> >
> >> > An installer could put the framework into the mono GAC 
> as well, if 
> >> > mono were installed.
> >> >
> >> It *could*, but do you really want to get into install order 
> >> dependencies with Mono? Installing 'nunit.framework' into 
> the .NET & 
> >> Mono GACs would add (IMHO unnecessary) complexity to the installer.
> >
> > Well, I haven't checked it out, but I think it's just a 
> single command 
> > that has to be run. I'm pretty sure we can do it if we want to.
> >
> >> > I think there are pros and cons of using the GAC but I'm 
> not sure I 
> >> > understand the distinction you're making.
> >> >
> >> Maybe 'platform' would have been a better word to use than 
> >> 'infrastructure'. I think the GAC is a good place for 
> assemblies that 
> >> are part of the platform (they are large and often bound to the 
> >> underlying OS). Using xcopy deployment for small library 
> assemblies 
> >> (like 'nunit.framework') works well and keeps things simple.
> >
> > That makes some sense.
> >
> >> The crux of the issue is - do we want the default to be for Visual 
> >> Studio to copy 'nunit.framework' into the output 
> directory? Copying 
> >> it into the output directory is the easiest way to ensure that it 
> >> works on .NET and Mono. What do we gain by not copying the 
> >> 'nunit.framework'
> >> assembly?
> >
> > I don't really see that as the crux. If we put it in the 
> GAC, then the 
> > copy setting won't matter. The copy in the GAC will be used 
> in either 
> > case.
> >
> > I'm not sure either way. Maybe we need a list of ways in which the 
> > decision impacts the user...
> >
> > 1. User must navigate to the install location and add a 
> reference in 
> > either case - or get it from the add reference dialog if 
> using Visual 
> > Studio.
> >
> > 2. User must copy the framework to the output directory if 
> not using 
> > the GAC.
> >
> > 3. User must deploy the framework if distributing tests in 
> either case 
> > - because it's not known what will be installed on the 
> machine of that 
> > user's user.
> >
> > Any other points to consider?
> >
> > Charlie
> >
> >> Regards,
> >> Jamie.
> >>
> >> --
> >> http://www.testdriven.net
> >> http://twitter.com/jcansdale
> >> http://weblogs.asp.net/nunitaddin
> >>
> >>
> >> On Fri, Jul 31, 2009 at 6:59 PM, Charlie Poole<charlie@xxxxxxxxx> 
> >> wrote:
> >> > Hi Jamie,
> >> >
> >> >> My best argument for not using the GAC is that it's runtime 
> >> >> implementation specific. If you default to using the GAC,
> >> you won't
> >> >> be able to execute your tests under Mono. This would be a shame 
> >> >> because NUnit does support Mono.
> >> >
> >> > That's not true, for two reasons:
> >> >
> >> > 1. Mono has a GAC, and currently the version of the 
> NUnit framework 
> >> > distributed with Mono is in it. Mono seems to use their GAC
> >> much more
> >> > extensively than Microsoft recommends for their .NET. An 
> installer 
> >> > could put the framework into the mono GAC as well, if mono were 
> >> > installed.
> >> >
> >> > 2. It has not been proposed that NUnit should _require_ the
> >> framework
> >> > to be in the GAC. NUnit doesn't care how the framework is
> >> accessed by
> >> > the tests, since it doesn't reference it. Of course, this
> >> discussion
> >> > may arise again for the core - but that's another matter.
> >> >
> >> >> The Mono team are also currently working on Mono Tools 
> for Visual 
> >> >> Studio (which will mean more people executing Mono from Visual
> >> >> Studio):
> >> >> http://www.go-mono.com/monovs/
> >> >>
> >> >> If you use TestDriven.Net's 'Test With > Mono' command with 
> >> >> 'nunit.framework' in the GAC, you will see:
> >> >>
> >> >> TestCase 'M:SomeTests.TestClass.Test'
> >> >> failed: Could not load file or assembly 'nunit.framework, 
> >> >> Version=2.5.1.9189, Culture=neutral,
> >> PublicKeyToken=96d09a1eb7f44a77'
> >> >> or one of its dependencies. The system cannot find the
> >> file specified.
> >> >>       System.IO.FileNotFoundException: Could not load file or 
> >> >> assembly 'nunit.framework, Version=2.5.1.9189, Culture=neutral, 
> >> >> PublicKeyToken=96d09a1eb7f44a77' or one of its 
> dependencies. The 
> >> >> system cannot find the file specified.
> >> >
> >> > If you didn't have the framework available, that's what 
> should have 
> >> > happened. You can make it available either by placing it in the 
> >> > ApplicationBase or by putting it into the *Mono* GAC.
> >> > I'm guessing you put it into the Microsoft GAC.
> >> >
> >> >> I think the GAC is most appropriate for infrastructure 
> assemblies 
> >> >> (e.g. System.*) not libraries (like 'nunit.framework').
> >> >
> >> > I think there are pros and cons of using the GAC but I'm 
> not sure I 
> >> > understand the distinction you're making. If you're writing
> >> tests, the
> >> > framework is definitely part of your infrastructure. Is 
> it because 
> >> > it's not Microsoft code?
> >> >
> >> > Charlie
> >> >
> >> >> Regards,
> >> >> Jamie.
> >> >>
> >> >> --
> >> >> http://www.testdriven.net
> >> >> http://twitter.com/jcansdale
> >> >> http://weblogs.asp.net/nunitaddin
> >> >>
> >> >>
> >> >> On Thu, Jul 30, 2009 at 7:11 PM, Charlie 
> Poole<charlie@xxxxxxxxx>
> >> >> wrote:
> >> >> > Hi Fabio and Everyone,
> >> >> >
> >> >> > Let's discuss this. Pros? Cons?
> >> >> >
> >> >> > Personally, I'm in favor. I think it makes life easier for
> >> >> users, some
> >> >> > of whom are confused by the need to copy the framework to
> >> >> the output
> >> >> > directory. They (falsely) assume that NUnit will find
> >> the framework
> >> >> > for them. It also makes life easier for any third-party
> >> runner that
> >> >> > needs to reference it.
> >> >> >
> >> >> > As far as the default, I'd vote for the GAC as the only
> >> >> option for the
> >> >> > msi install. If someone wants to run it from their 
> project tree 
> >> >> > instead, they can use the binary zip.
> >> >> >
> >> >> > Charlie
> >> >> >
> >> >> > ________________________________
> >> >> > From: nunit-dev-bounces+charlie=nunit.com@xxxxxxxxxxxxxxxxxxx
> >> >> >
> >> [mailto:nunit-dev-bounces+charlie=nunit.com@xxxxxxxxxxxxxxxxxxx] On
> >> >> > Behalf Of Fabio Maulo
> >> >> > Sent: Thursday, July 30, 2009 4:54 AM
> >> >> > To: nunit-dev@xxxxxxxxxxxxxxxxxxx
> >> >> > Subject: Re: [Nunit-dev] Installation layout for NUnit V3
> >> >> >
> >> >> > I have only one issue about installation.
> >> >> > IMO we should have an explicit option to install the
> >> >> framework in the
> >> >> > GAC and the default should be "false".
> >> >> >
> >> >> > 2009/7/30 Andreas Schlapsi <a.schlapsi@xxxxxx>
> >> >> >>
> >> >> >> Hi Charlie,
> >> >> >>
> >> >> >> I created a prototype for the NUnit Framework Installer
> >> >> yesterday. It
> >> >> >> packages the NUnit Framework for .NET 1.1 and .NET 2.0
> >> >> (and later for
> >> >> >> .NET 3.5 and 4.0) and suppresses all variants in the
> >> feature tree
> >> >> >> without corresponding .NET version installed on the target
> >> >> computer.
> >> >> >>
> >> >> >> It installs the framework assemblies under <Program 
> >> >> >> Files>\NUnit
> >> >> >> 3.0\Framework\net-1.1 or <Program Files>\NUnit
> >> >> 3.0\Framework\net-2.0.
> >> >> >>
> >> >> >> What about documentation? Will the framework documentation
> >> >> be separated?
> >> >> >>
> >> >> >> Andreas
> >> >> >>
> >> >> >>
> >> >> >> Charlie Poole wrote:
> >> >> >> > Hi Andreas,
> >> >> >> >
> >> >> >> > In breaking NUnit into multiple projects, I tried to
> >> >> take several
> >> >> >> > things into account:
> >> >> >> >   * Different teams working on different projects
> >> >> >> >   * Independent release cycles
> >> >> >> >   * Possibility of third-party alternatives
> >> >> >> >   * Separate installation.
> >> >> >> >
> >> >> >> > At the moment, I think we only need to decide how to
> >> install the
> >> >> >> > framework, since we only have a framework project for
> >> NUnit 3.0.
> >> >> >> > When we add - for example - a gui project, we'll of
> >> >> course need a
> >> >> >> > separate install for that.
> >> >> >> >
> >> >> >> > In the future, we may want to create a combined 
> installer for 
> >> >> >> > windows - one that bundles one or more frameworks
> >> with gui and
> >> >> >> > console runners and possibly other stuff. Note 
> that this is a 
> >> >> >> > Windows-only problem, since linux distros have package
> >> >> management
> >> >> >> > systems to take care of dependencies between
> >> individual packages.
> >> >> >> >
> >> >> >> > So, for now I think the issue is how to structure the
> >> >> installation
> >> >> >> > of the framework only. This is not as simple as it
> >> sounds, since
> >> >> >> > the framework is tailored to a version of .NET and
> >> there may be
> >> >> >> > multiple versions on a machine.
> >> >> >> >
> >> >> >> > BTW, There will be a place on a wiki to actually post
> >> specs very
> >> >> >> > soon. For now we have to discuss here and/or post
> >> >> directly on the
> >> >> >> > Whiteboard.
> >> >> >> >
> >> >> >> > Charlie
> >> >> >> >
> >> >> >> >> -----Original Message-----
> >> >> >> >> From: 
> >> >> >> >> nunit-dev-bounces+charlie=nunit.com@xxxxxxxxxxxxxxxxxxx
> >> >> >> >>
> >> [mailto:nunit-dev-bounces+charlie=nunit.com@xxxxxxxxxxxxxxxxxx
> >> >> >> >> t] On Behalf Of Andreas Schlapsi
> >> >> >> >> Sent: Tuesday, July 28, 2009 10:07 AM
> >> >> >> >> To: NUnit Developer Mailing List
> >> >> >> >> Subject: [Nunit-dev] Installation layout for NUnit V3
> >> >> >> >>
> >> >> >> >> Hi,
> >> >> >> >>
> >> >> >> >> I'm working on the installer blueprint
> >> >> >> >>
> >> (https://blueprints.launchpad.net/nunit-3.0/+spec/install-proj
> >> >> >> >> ect) and one of the todos is to decide on an
> >> >> installation layout.
> >> >> >> >> It should allow multiple frameworks to be installed
> >> separately
> >> >> >> >> from runners like nunit-gui.
> >> >> >> >>
> >> >> >> >> Does this mean that we want separate installers for the
> >> >> framework
> >> >> >> >> and the runners? Do we need an installer for the
> >> framework? The
> >> >> >> >> framework assemblies are often checked in to 
> source control.
> >> >> >> >>
> >> >> >> >> Andreas
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> _______________________________________________
> >> >> >> >> Mailing list: https://launchpad.net/~nunit-dev 
> Post to     :
> >> >> >> >> nunit-dev@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> >> >> >> >> https://launchpad.net/~nunit-dev More help   :
> >> >> >> >> https://help.launchpad.net/ListHelp
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > _______________________________________________
> >> >> >> > Mailing list: https://launchpad.net/~nunit-dev 
> Post to     :
> >> >> >> > nunit-dev@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> >> >> >> > https://launchpad.net/~nunit-dev More help   :
> >> >> >> > https://help.launchpad.net/ListHelp
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> Mailing list: https://launchpad.net/~nunit-dev Post to     :
> >> >> >> nunit-dev@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> >> >> >> https://launchpad.net/~nunit-dev More help   :
> >> >> >> https://help.launchpad.net/ListHelp
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Fabio Maulo
> >> >> >
> >> >> > _______________________________________________
> >> >> > Mailing list: https://launchpad.net/~nunit-dev Post to     :
> >> >> > nunit-dev@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> >> >> > https://launchpad.net/~nunit-dev More help   :
> >> >> > https://help.launchpad.net/ListHelp
> >> >> >
> >> >> >
> >> >>
> >> >> _______________________________________________
> >> >> Mailing list: https://launchpad.net/~nunit-dev Post to     :
> >> >> nunit-dev@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> >> >> https://launchpad.net/~nunit-dev More help   :
> >> >> https://help.launchpad.net/ListHelp
> >> >>
> >> >
> >> >
> >> >
> >> >
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~nunit-dev Post to     : 
> >> nunit-dev@xxxxxxxxxxxxxxxxxxx Unsubscribe : 
> >> https://launchpad.net/~nunit-dev More help   : 
> >> https://help.launchpad.net/ListHelp
> >>
> >
> >
> >
> >
>