← Back to team overview

nunit-dev team mailing list archive

Re: Framework in GAC

 

> 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?
>
Yes, that makes sense. Can we make it so that people have to
explicitly select it in the install? Because it may have unintended
consequences, I'd rather it wasn't part of a 'Default' or 'Full'
install.

Regards,
Jamie.

--
http://www.testdriven.net
http://twitter.com/jcansdale
http://weblogs.asp.net/nunitaddin



On Mon, Aug 3, 2009 at 8:48 PM, Charlie Poole<charlie@xxxxxxxxx> wrote:
> 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
>> >>
>> >
>> >
>> >
>> >
>>
>
>
>
>



Follow ups

References