nunit-dev team mailing list archive

["Charlie Poole" <charlie@xxxxxxxxx>]

Hi Andreas,

OK... I downloaded WiX 3.0 and can answer some of my own 
questions now...

> I merged my copy of trunk to get your changes. What I see is 
> that we have a type of project that is not available in my 
> copy of VS 2008. Is that an extension to WiX I need to 
> install? Is WiX 3.0 only useable under VS?

No... it comes with instructions about how to use it from
the command line, from MSBuild and from NAnt as well as
Visual Studio.
 
> We hadn't talked about this before, but I hesitate to add a 
> Visual Studio dependency in order to build the installer. In 
> the past, we used a VS Install project, but went to straight 
> WiX using the NAnt script because lots of people who want to 
> build it don't have VS available. Can we still do it that way?

I'm of two minds here. I did the original installer completely
by hand - a lot of it in notepad. OTOH, I'm guessing the
Votive plugin for Visual Studio allowed you to put it all
together a lot more quickly.

> I can install whatever is needed to test this out but I'd 
> like to get away from any VS dependency if we can.

I can see that there is no dependency on VS in order to build
the msi after changing the framework. We can have a package-msi
target in the script, just as we now do.

The dependency is for making any changes in the install itself.
I see two ways to go here:

1. Keep the VS solution. Major changes will have to be made by
someone with access to VS2008. Many minor changes could probably
be made simply by editing the wxs files directly.

2. Drop the solution and go back to hand editing files.

Are there other choices?

Of those two choices, I'm surprising myself by suggesting that
#1 has the edge. 

* It does create a dependency on VS, but a limited one.
* VS is not needed to generate a new package after changing
  the framework.
* VS is not really needed even to modify the package logic
  itself - it just makes it a lot easier.

If there is another way to build a WiX installer - with 
SharpDevelop for example - I'd like to support that as well,
but if not I'm OK with having the solution as a convenience
for VS users.

That said, I don't think we should do anything that locks
it in further, like adding extensions or user logic in the
same solution.

BTW, I'm assuming the installer project won't work with
C# Express, right?

Charlie

PS: I'll send a separate note reviewing the change itself.

Charlie

> 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: Thursday, July 30, 2009 1:29 PM
> > To: 'NUnit Developer Mailing List'
> > Subject: Re: [Nunit-dev] Installation layout for NUnit V3
> > 
> > Hi Charlie,
> > 
> > I've just pushed my commits on the installer. There are still some 
> > issues with UAC on Vista, which I'd like to solve.
> > Besides, it requires admin privileges for now.
> > 
> > I thought about a folder structure similar to your 
> proposal, but I was 
> > too conservative. I agree with you. I changed the folder 
> structure of 
> > the installer to this:
> > 
> > NUnit
> >   Framework
> >     3.0
> >       net-1.1   (if available)
> >       net-2.0   (if available)
> >     3.1
> >       net-1.1
> >       net-2.0
> > 
> > If you use the Custom setup type the installer will let you 
> choose to 
> > install the assemblies in the GAC. The checkbox appears after the 
> > feature tree. The installer defines two components for the 
> framework 
> > assembly with conditions which are mutually exclusive. I'm 
> not content 
> > with the solution, since it duplicates the definition of the 
> > components for the assemblies and it causes some warnings 
> from the ICE 
> > validation.
> > 
> > Andreas
> > 
> > 
> > Charlie Poole wrote:
> > > Hi Andreas,
> > > 
> > > Cool! I'd like to do a snapshot with it included.
> > > 
> > > Putting Framework under nunit-3.0 seems to imply that the version 
> > > numbers will be in synch. But imagine some future user who
> > is running
> > > the 3.0 Gui but has tests that use the 3.0, 3.1 and 3.2
> > frameworks -
> > > which we released separately as improvements were added.
> > > 
> > > Therefore, I think this should be (something like):
> > > 
> > > NUnit
> > >   Framework
> > >      3.0
> > >      3.1
> > >      3.2
> > >   NUnit Gui
> > >      3.0
> > > 
> > > OR
> > > 
> > > NUnitFramework
> > >    3.0
> > >    3.1
> > >    3.2
> > > NUnit 3.0
> > > 
> > > OR
> > > 
> > > NUnitFramework
> > >    3.0
> > >    3.1
> > >    3.2
> > > SomeOtherNameForTheGUI 3.0 (or 1.0?)
> > > 
> > > Any other ideas?
> > > 
> > > 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: Thursday, July 30, 2009 4:48 AM
> > >> To: 'NUnit Developer Mailing List'
> > >> Subject: Re: [Nunit-dev] Installation layout for NUnit V3
> > >>
> > >> 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
> > 
> > 
> > _______________________________________________
> > 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
> > 
>