[WiX-users] Including all files under a directory

Discussion:

Anand Murugesan

2004-05-03 23:42:58 UTC

Hi All,
I am trying to add all the files (including the subdirectories), under
C:\software\package1 into my MSI.
I am using the following MSI segment. But, it includes only the top
level files in the package1 directory. How do I make it to drill down
to all subdirectories ?
*<FileGroup Prefix='bla' DiskId='1' src='C:\software\package1' />

*Is this the right approach, or should I consider creating a separate
archieve or cab file and reference it in my wsx file. If thats the
better solution, how do I do that for the above mentioned scenario ?
*
*Thanks,
Anand.

Rob Mensching

2004-05-04 00:11:36 UTC

Permalink

The <FileGroup/> element is a very dangerous thing to use and I always
discourage its use. Autogenerating Components (which would be necessary to
add Files from subdirectories) isn't just dangerous, it is down right scary.
You have to understand the Component Rules
(http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx) and then you'll
see why autogenerating Components for each of your Directories is a really
scary thing to do.

The WiX toolset does not autogenerate Components. Full stop.

_____

From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Anand Murugesan
Sent: Monday, May 03, 2004 4:43 PM
To: wix-***@lists.sourceforge.net
Subject: [WiX-users] Including all files under a directory

Hi All,
I am trying to add all the files (including the subdirectories), under
C:\software\package1 into my MSI.
I am using the following MSI segment. But, it includes only the top level
files in the package1 directory. How do I make it to drill down to all
subdirectories ?
<FileGroup Prefix='bla' DiskId='1' src='C:\software\package1' />

Is this the right approach, or should I consider creating a separate
archieve or cab file and reference it in my wsx file. If thats the better
solution, how do I do that for the above mentioned scenario ?

Thanks,
Anand.

n***@ni.com

2004-05-04 21:57:16 UTC

Permalink

I am using build 2.0.1629.0. I don't think I saw this issue reported as a
bug... yet.
----------------------------------------------------------

I have a source file myProj.wxs

This file has the line <? include myShared.wxi ?>

If I have the file myShared.wxi in the same folder as myProj.wxs,
everything is dandy.

Now I move the shared file to c:\sharedIncludes\myShared.wxi

I just cant get things to work anymore . I changed the include line to
have the full path to the new location, tried using
$(var.sharedPath)\myShared.wxi, also tried the -i commandline switch. If I
get the path wrong candle complains that it cant find the file.

But if the path is correct, the include file is just silently ignored. The
stuff from the include file don't make it to the output. If I introduce
errors in the include file, still no complaints. Its just completely
ignored.

Anyone have any ideas?

Thanks
Naren

Orion Edwards

2004-05-05 00:25:45 UTC

Permalink

Hi. I'm trying to insert a type 38 (inline vbscript call) for simple debugging.

Wix can generate Type 54's (vbscript in property) fine by something like this:

<Property Id="VBSDebugCode" Value="somevbscriptcode"/>
<CustomAction Id="CaVBSDebug" Property="VBSDebugCode" VBScriptCall=""/>

However, how do I make a type 38?
If I use the following code:

<CustomAction Id="CaVBSDebug" VBScriptCall="somevbscriptcode"/>

then wix generates a type 6 CA - VBScript stored in the binary table, rather
than the type 38 which is what I'd expect it to produce. Logically a type 6
would be generated by the following:

<Binary Id="VBSDebugFile" src="something.vbs"/>
<CustomAction Id="VBSDebug" BinaryKey="VBSDebugFile" VBScriptCall=""/>

Is this a bug? If not, how exactly DO I go about making a type 38 CA?

Thanks, Orion.

Orion Edwards

2004-05-05 00:36:48 UTC

Permalink

Sorry, found the answer myself.

the API documentation says that a type 38 is msidbCustomActionTypeVBScript +
msidbCustomActionTypeDirectory

So putting the following into wix produced a type 38

<CustomAction Directory="somedirectory" VBScriptCall="somevbscriptcode"/>

This works - the CA is generated, called and works successfully, however it puts
the directory name into the Source column of the customaction table, where the
documentation says the Source column should be null for a type 38.

I can't put Directory="null" or Directory="" or any other such things, because
then wix fails to resolve that directory and doesn't build.

The end result, according to the API documentation is wrong, but it does work
successfully... I suppose its up to the devs to decide if they want to do
anything about it.

Thanks, Orion.

Rob Mensching

2004-05-05 00:45:55 UTC

Permalink

Heh, this is funny. Someone else (internal to MS) reported this bug just
yesterday. Expect to see a fix Thursday assuming all goes well tonight.

-----Original Message-----
From: wix-devs-***@lists.sourceforge.net
[mailto:wix-devs-***@lists.sourceforge.net] On Behalf Of Orion Edwards
Sent: Tuesday, May 04, 2004 17:37
Subject: [WiX-devs] Re: [WiX-users] Type 38 CustomAction

Sorry, found the answer myself.

the API documentation says that a type 38 is msidbCustomActionTypeVBScript +
msidbCustomActionTypeDirectory

So putting the following into wix produced a type 38

<CustomAction Directory="somedirectory" VBScriptCall="somevbscriptcode"/>

This works - the CA is generated, called and works successfully, however it
puts
the directory name into the Source column of the customaction table, where
the
documentation says the Source column should be null for a type 38.

I can't put Directory="null" or Directory="" or any other such things,
because
then wix fails to resolve that directory and doesn't build.

The end result, according to the API documentation is wrong, but it does
work
successfully... I suppose its up to the devs to decide if they want to do
anything about it.

Thanks, Orion.

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id66&op=ick

Riko Eksteen

2004-05-05 09:14:44 UTC

Permalink

I finally understand why the FileGroup element is so dangerous, and I won't be using it again (thanks Rob).

I had a look at the component rules in the SDK again, and realised that the requirements there doesn't fit with FileGroup. Specifically, one should never add or remove resources from a component without changing the component code, otherwise those resources might not be removed/repaired/upgraded etc. Think this is pretty self-evident. If that is the case, "The <FileGroup/> element is a very dangerous thing to use" because if files in a folder are included this way, there is no way to know whether you actually add new resources to an already existing component.

That sent me an a mission to find out how InstallShield's dynamic file linking works, because it would be subject to the same flaw in logic, so to speak. InstallShield's dynamic linking includes both subfolders and files, and what it actually does behind your back is to create new components per subfolder, include all the files, and set the first as the KeyPath. It also generates new component codes at build time, so that the above requirement is met. So this would work, theoretically (we certainly haven't had
problems with it), but it does make it hard to keep track of what files exactly are included in your components, and might lead to some problems when doing upgrades.

Anyway, this brings me back to the right way to add files in WiX - manually. This is fine and dandy, except that I've spent just about a whole day adding every single xml file in the specific product (there 696 of these files and 212 related folders) and I'm still going. This is a bit of a problem: apart from the fact that the text-based entry method is error prone, it will be a hell of an ask to track changes and add them correctly. It is here that InstallShield has a significant advantage.

I spoke to some of our developers yesterday and they are not very keen to use something like this - they want an easier way to include files etc. So now I feel like I'm back to square one - I don't want to use a product like InstallShield, because 1) it's expensive to distribute all round 2) it does stuff behind your back 3) it doesn't create the cleanest MSIs (unnecessary tables etc.). I would like something that would allow the developers to author and maintain their own MSIs, but Visual Studio Installer is too high-level (hides everything away) and it looks like WiX will be difficult to use for large projects, despite it's many advantages.

Any thoughts?

-----Original Message-----
From: Rob Mensching [mailto:***@users.sourceforge.net]
Sent: 04 May 2004 02:12
To: 'Anand Murugesan'; wix-***@lists.sourceforge.net
Subject: RE: [WiX-users] Including all files under a directory

The <FileGroup/> element is a very dangerous thing to use and I always discourage its use. Autogenerating Components (which would be necessary to add Files from subdirectories) isn't just dangerous, it is down right scary. You have to understand the Component Rules ( http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx) and then you'll see why autogenerating Components for each of your Directories is a really scary thing to do.

The WiX toolset does not autogenerate Components. Full stop.

_____

From: wix-users-***@lists.sourceforge.net [mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Anand Murugesan
Sent: Monday, May 03, 2004 4:43 PM
To: wix-***@lists.sourceforge.net
Subject: [WiX-users] Including all files under a directory

Hi All,
I am trying to add all the files (including the subdirectories), under C:\software\package1 into my MSI.
I am using the following MSI segment. But, it includes only the top level files in the package1 directory. How do I make it to drill down to all subdirectories ?
<FileGroup Prefix='bla' DiskId='1' src='C:\software\package1' />

Is this the right approach, or should I consider creating a separate archieve or cab file and reference it in my wsx file. If thats the better solution, how do I do that for the above mentioned scenario ?

Thanks,
Anand.

Orion Edwards

2004-05-05 12:39:20 UTC

Permalink

I spoke to some of our developers yesterday and they are not very keen to use something like this - they want an easier way to include files etc. So now I feel like I'm back to square one - I don't want to use a product like InstallShield, because 1) it's expensive to distribute all round 2) it does stuff behind your back 3) it doesn't create the cleanest MSIs (unnecessary tables etc.). I would like something that would allow the developers to author and maintain their own MSIs, but Visual Studio Installer is too high-level (hides everything away) and it looks like WiX will be difficult to use for large projects, despite it's many advantages.

Any thoughts?

I agree. I've got a lot of experience with Installshield and (imho) it's awful. Does god knows what in the background, which slows things down and adds complexity (more complexity == more bugs). Don't even get

Steve Christensen

2004-05-05 18:26:55 UTC

Permalink

Post by Orion Edwards
I agree. I've got a lot of experience with Installshield and (imho)
it's awful. Does god knows what in the background, which slows things
down and adds complexity (more complexity == more bugs). Don't even
get me started on "Installscript" :-)

Jason Swager

2004-05-05 13:28:50 UTC

Permalink

I've encountered the same issues; too many files to type into WIX. In our
case, we've currently got about 66,000 files per install. We don't put
every file in its own component, but it's still a massive amount of typing.
Prior to WIX, we were using WISE, which appears to have the same problems as
Install Shield and does things behind your back.

However, to at least make the initial work easier, we wrote a quick little
program that simply walks through specific directory and/or subdirectories,
building a partial WIX fragment as it goes. For every directory/file found,
it would expand the WIX fragment with the appropriate XML. Each file was
assigned a new component ID. After each fragment was built, a developer
would go and decide which files could be grouped into a single component,
and which ones would need to be on their own. That makes it MUCH easier to
maintain.

Jason

-----Original Message-----
From: Orion Edwards [mailto:***@coke.net.nz]
Sent: Wednesday, May 05, 2004 5:39 AM
To: wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Including all files under a directory

I spoke to some of our developers yesterday and they are not very keen to
use something like this - they want an easier way to include files etc. So
now I feel like I'm back to square one - I don't want to use a product like
InstallShield, because 1) it's expensive to distribute all round 2) it does
stuff behind your back 3) it doesn't create the cleanest MSIs (unnecessary
tables etc.). I would like something that would allow the developers to
author and maintain their own MSIs, but Visual Studio Installer is too
high-level (hides everything away) and it looks like WiX will be difficult
to use for large projects, despite it's many advantages.

Any thoughts?

I agree. I've got a lot of experience with Installshield and (imho) it's
awful. Does god knows what in the background, which slows things down and
adds complexity (more complexity == more bugs). Don't even get me started on

Jamie Cansdale

2004-05-05 14:14:33 UTC

Permalink

I've been working on a command line tool that updates the File, Directory
and Component elements in a WXS file based on the projects in a Visual
Studio solution. At the moment it copies all files with a 'Build Action' of
'Content' and all project outputs for a specified solution configuration.
Each file gets its own File and Component element allowing with any
Directory elements as needed. The Component.Guid, Id and File.Id are based
on a hash of the relative path (I know the Component.Guid should be combined
with something else!). It is very much a work in progress. Let me know
what I'm missing or doing wrong! Here is an example of what it outputs at
the moment.

(Here's a build of NUnitAddIn created using it)

http://weblogs.asp.net/nunitaddin/archive/2004/05/01/124453.aspx

Because it updates the WXS file rather than recreating I can add things like
custom actions. Because the File.Id and ComponentId are a hash of the
project items relative path they will remain consistent between updates. It
is everything under ModuleDir that has been generated.

Should File.KeyPath be set to 'yes'?

Should Component.Id be randomized on each update?

<?xml version="1.0" encoding="utf-8"?>

<Wix xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://schemas.microsoft.com/wix/2003/01/wi">

<Module Id="NUnitAddin.sln" Guid="5FA9934D3F3341BBB28C6026583BC45C"
Language="1033" Version="1.0.0.0">

<Package Id="3807327122724060A7423BF1DE5C7FA5" Description="From
solution 'NUnitAddin.sln'" Comments="Auto generated with Sln2Wix"
Manufacturer="Mutant Design" InstallerVersion="200" Compressed="yes" />

<InstallExecuteSequence>



<Custom Action="Install"
After="InstallFinalize">$C_a14fc90fa19a9a5acdbea8f24e4cb8ef>2</Custom>



<Custom Action="Uninstall"
Before="MsiUnpublishAssemblies">$C_a14fc90fa19a9a5acdbea8f24e4cb8ef=2</Custo
m>

</InstallExecuteSequence>

<CustomAction Id="Install" FileKey="F_a14fc90fa19a9a5acdbea8f24e4cb8ef"
ExeCommand="/install" Execute="immediate" />

<CustomAction Id="Uninstall"
FileKey="F_a14fc90fa19a9a5acdbea8f24e4cb8ef" ExeCommand="/uninstall"
Execute="immediate" />

<Directory Id="TARGETDIR" Name="SourceDir">

<Directory Id="ModuleDir" Name=".">

<Directory Id="D_605c646ba3f747c9b24bb1a277193aa2" Name="icons"
LongName="icons">

<Component Id="C_61fbcd6caea5c8e88f720a55d9df8e02"
Guid="61fbcd6c-aea5-c8e8-8f72-0a55d9df8e02">

<File Id="F_61fbcd6caea5c8e88f720a55d9df8e02" Name="Debug.ico"
LongName="Debug.ico" src="NUnitAddin\icons\Debug.ico" />

</Component>

<Component Id="C_a8db7eb234f62c179194d360ada47525"
Guid="a8db7eb2-34f6-2c17-9194-d360ada47525">

<File Id="F_a8db7eb234f62c179194d360ada47525" Name="NUnit.ico"
LongName="NUnit.ico" src="NUnitAddin\icons\NUnit.ico" />

</Component>

<Component Id="C_be78b109c9f515e5a360bcd79a4822ea"
Guid="be78b109-c9f5-15e5-a360-bcd79a4822ea">

<File Id="F_be78b109c9f515e5a360bcd79a4822ea" Name="Runtime.ico"
LongName="Runtime.ico" src="NUnitAddin\icons\Runtime.ico" />

</Component>

<Component Id="C_0fa6f464d88f67139a06edd87e5c5c0e"
Guid="0fa6f464-d88f-6713-9a06-edd87e5c5c0e">

<File Id="F_0fa6f464d88f67139a06edd87e5c5c0e"
Name="VISUAL~1.ICO" LongName="VisualStudio.ico"
src="NUnitAddin\icons\VisualStudio.ico" />

</Component>

</Directory>

<Directory Id="D_577b9fd8db914fc3b27da51091ab143b" Name="runtimes"
LongName="runtimes">

<Component Id="C_d02d696b9530b17f7c0fb25fbc756d19"
Guid="d02d696b-9530-b17f-7c0f-b25fbc756d19">

<File Id="F_d02d696b9530b17f7c0fb25fbc756d19"
Name="CDP_AP~1.CON" LongName="CDP_Apartment.config"
src="NUnitAddin\runtimes\CDP_Apartment.config" />

</Component>

<Component Id="C_992d17046bcf574f67a260aba454b637"
Guid="992d1704-6bcf-574f-67a2-60aba454b637">

<File Id="F_992d17046bcf574f67a260aba454b637"
Name="CDP_MA~1.CON" LongName="CDP_Marshaling.config"
src="NUnitAddin\runtimes\CDP_Marshaling.config" />

</Component>

<Component Id="C_3626c8bac9756919f631b830d6213c85"
Guid="3626c8ba-c975-6919-f631-b830d6213c85">

<File Id="F_3626c8bac9756919f631b830d6213c85" Name="MONO~1.CON"
LongName="mono.config" src="NUnitAddin\runtimes\mono.config" />

</Component>

<Component Id="C_4b2fb538595fafa3207fb503cbcc730c"
Guid="4b2fb538-595f-afa3-207f-b503cbcc730c">

<File Id="F_4b2fb538595fafa3207fb503cbcc730c" Name="NET10~1.CON"
LongName="net10.config" src="NUnitAddin\runtimes\net10.config" />

</Component>

<Component Id="C_14eb7860f8128506c36a706e0e14a193"
Guid="14eb7860-f812-8506-c36a-706e0e14a193">

<File Id="F_14eb7860f8128506c36a706e0e14a193" Name="NET11~1.CON"
LongName="net11.config" src="NUnitAddin\runtimes\net11.config" />

</Component>

<Component Id="C_076902cce67640035c94c11cde5c617c"
Guid="076902cc-e676-4003-5c94-c11cde5c617c">

<File Id="F_076902cce67640035c94c11cde5c617c" Name="NET12~1.CON"
LongName="net12.config" src="NUnitAddin\runtimes\net12.config" />

</Component>

<Component Id="C_97fbf17a2993af20f32712832b5fbcc7"
Guid="97fbf17a-2993-af20-f327-12832b5fbcc7">

<File Id="F_97fbf17a2993af20f32712832b5fbcc7" Name="NET20~1.CON"
LongName="net20.config" src="NUnitAddin\runtimes\net20.config" />

</Component>

</Directory>

<Directory Id="D_e8a17bec33054952bb6f31dbdb2e7a81" Name="lib"
LongName="lib">

<Component Id="C_d68012501a3e4796a09f43b0208902b1"
Guid="d6801250-1a3e-4796-a09f-43b0208902b1">

<File Id="F_d68012501a3e4796a09f43b0208902b1"
Name="MUTANT~3.DLL" LongName="MutantDesign.ManagedAddIns.dll"
src="..\ManagedAddIns\Tests\bin\MutantDesign.ManagedAddIns.dll" />

</Component>

<Component Id="C_79ba08747349da554584d763e9c3b536"
Guid="79ba0874-7349-da55-4584-d763e9c3b536">

<File Id="F_79ba08747349da554584d763e9c3b536"
Name="MUTANT~3.DLL" LongName="MutantDesign.ManagedAddIns.Services.dll"
src="..\ManagedAddIns\Tests\bin\MutantDesign.ManagedAddIns.Services.dll" />

</Component>

</Directory>

<Component Id="C_0d57b7d4022f1f0ee5cf9f3dc3e40020"
Guid="0d57b7d4-022f-1f0e-e5cf-9f3dc3e40020">

<File Id="F_0d57b7d4022f1f0ee5cf9f3dc3e40020" Name="MUTANT~1.DLL"
LongName="MutantDesign.ManagedAddIns.Services.dll"
src="NUnitAddin\..\..\ManagedAddIns\Tests\bin\MutantDesign.ManagedAddIns.Ser
vices.dll" />

</Component>

<Component Id="C_fdfe27ba7225eefb183c7fa00e00c9b4"
Guid="fdfe27ba-7225-eefb-183c-7fa00e00c9b4">

<File Id="F_fdfe27ba7225eefb183c7fa00e00c9b4" Name="Notes.htm"
LongName="Notes.htm" src="NUnitAddin\Notes.htm" />

</Component>

<Component Id="C_43a46a698b77ff2ea398a9c3ce6f717f"
Guid="43a46a69-8b77-ff2e-a398-a9c3ce6f717f">

<File Id="F_43a46a698b77ff2ea398a9c3ce6f717f" Name="NUNITA~1.CON"
LongName="nunitaddin.config" src="NUnitAddin\nunitaddin.config" />

</Component>

<Component Id="C_a14fc90fa19a9a5acdbea8f24e4cb8ef"
Guid="a14fc90f-a19a-9a5a-cdbe-a8f24e4cb8ef">

<File Id="F_a14fc90fa19a9a5acdbea8f24e4cb8ef" Name="NUNITA~1.EXE"
LongName="NUnitAddin.exe" src="NUnitAddin\bin\Debug\NUnitAddin.exe" />

</Component>

<Component Id="C_d1f9216d472c9165285a3517afc5c8c6"
Guid="d1f9216d-472c-9165-285a-3517afc5c8c6">

<File Id="F_d1f9216d472c9165285a3517afc5c8c6" Name="NUNITA~2.CON"
LongName="NUnitAddin.exe.config"
src="NUnitAddin\bin\Debug\NUnitAddin.exe.config" />

</Component>

<Component Id="C_4c92e542556b64cb5e7ced616636c9bd"
Guid="4c92e542-556b-64cb-5e7c-ed616636c9bd">

<File Id="F_4c92e542556b64cb5e7ced616636c9bd" Name="MUTANT~1.DLL"
LongName="MutantDesign.dll" src="MutantDesign\bin\Debug\MutantDesign.dll" />

</Component>

<Component Id="C_bbbb3733bacceab10740626158732f7a"
Guid="bbbb3733-bacc-eab1-0740-626158732f7a">

<File Id="F_bbbb3733bacceab10740626158732f7a" Name="MUTANT~1.DLL"
LongName="MutantDesign.EnvDte.dll"
src="MutantDesign.EnvDte\bin\Debug\MutantDesign.EnvDte.dll" />

</Component>

<Component Id="C_c26efcbb5aa7ad9545db861cc3e188fd"
Guid="c26efcbb-5aa7-ad95-45db-861cc3e188fd">

<File Id="F_c26efcbb5aa7ad9545db861cc3e188fd" Name="NUNITA~1.DLL"
LongName="NUnitAddin.TestRunner.dll"
src="NUnitAddin.TestRunner\bin\Debug\NUnitAddin.TestRunner.dll" />

</Component>

<Component Id="C_cea1597c41a7fc9d2a6ad6174ed3829f"
Guid="cea1597c-41a7-fc9d-2a6a-d6174ed3829f">

<File Id="F_cea1597c41a7fc9d2a6ad6174ed3829f" Name="NUNITA~1.DLL"
LongName="NUnitAddin.TestRunner.Framework.dll"
src="NUnitAddin.TestRunner.Framework\bin\Debug\NUnitAddin.TestRunner.Framewo
rk.dll" />

</Component>

<Component Id="C_dd1cc65557fa1b0aad383b8241a69d08"
Guid="dd1cc655-57fa-1b0a-ad38-3b8241a69d08">

<File Id="F_dd1cc65557fa1b0aad383b8241a69d08" Name="NUNITA~1.DLL"
LongName="NUnitAddin.TestRunner.Runtimes.dll"
src="NUnitAddin.TestRunner.Runtimes\bin\Debug\NUnitAddin.TestRunner.Runtimes
.dll" />

</Component>

<Component Id="C_336119253d86417257327f18a666614f"
Guid="33611925-3d86-4172-5732-7f18a666614f">

<File Id="F_336119253d86417257327f18a666614f" Name="NUNITA~1.DLL"
LongName="NUnitAddin.AdHoc.dll"
src="NUnitAddin.AdHoc\bin\Debug\NUnitAddin.AdHoc.dll" />

</Component>

<Component Id="C_c4fbba73ae9ea15c7c8da7260d564159"
Guid="c4fbba73-ae9e-a15c-7c8d-a7260d564159">

<File Id="F_c4fbba73ae9ea15c7c8da7260d564159" Name="NUNITC~1.DLL"
LongName="nunit.core.dll" src="NUnitAddin.NUnit\..\bin\NUnit\nunit.core.dll"
/>

</Component>

<Component Id="C_7d8d4deb750f1cdb13877abcd095bcd7"
Guid="7d8d4deb-750f-1cdb-1387-7abcd095bcd7">

<File Id="F_7d8d4deb750f1cdb13877abcd095bcd7" Name="NUNITF~1.DLL"
LongName="nunit.framework.dll"
src="NUnitAddin.NUnit\..\bin\NUnit\nunit.framework.dll" />

</Component>

<Component Id="C_70d92e0fa3048fcbc862c509bf833e4c"
Guid="70d92e0f-a304-8fcb-c862-c509bf833e4c">

<File Id="F_70d92e0fa3048fcbc862c509bf833e4c" Name="NUNITU~1.DLL"
LongName="nunit.uikit.dll"
src="NUnitAddin.NUnit\..\bin\NUnit\nunit.uikit.dll" />

</Component>

<Component Id="C_2676255db2265d5b5701d20b35c1da89"
Guid="2676255d-b226-5d5b-5701-d20b35c1da89">

<File Id="F_2676255db2265d5b5701d20b35c1da89" Name="NUNITU~1.DLL"
LongName="nunit.util.dll" src="NUnitAddin.NUnit\..\bin\NUnit\nunit.util.dll"
/>

</Component>

<Component Id="C_b88e98ae33aebcedf8500d6283320836"
Guid="b88e98ae-33ae-bced-f850-0d6283320836">

<File Id="F_b88e98ae33aebcedf8500d6283320836" Name="NUNIT-~1.EXE"
LongName="nunit-console.exe"
src="NUnitAddin.NUnit\..\bin\NUnit\nunit-console.exe" />

</Component>

<Component Id="C_6b3a3e57c4a46a6851e05d8ed4020963"
Guid="6b3a3e57-c4a4-6a68-51e0-5d8ed4020963">

<File Id="F_6b3a3e57c4a46a6851e05d8ed4020963" Name="NUNIT-~1.EXE"
LongName="nunit-gui.exe" src="NUnitAddin.NUnit\..\bin\NUnit\nunit-gui.exe"
/>

</Component>

<Component Id="C_a05778b889dc8f8bc2db9a3ec575f23a"
Guid="a05778b8-89dc-8f8b-c2db-9a3ec575f23a">

<File Id="F_a05778b889dc8f8bc2db9a3ec575f23a" Name="NUNITA~1.DLL"
LongName="NUnitAddin.NUnit.dll"
src="NUnitAddin.NUnit\bin\Debug\NUnitAddin.NUnit.dll" />

</Component>

<Component Id="C_7f34010c9d32ab9b9b72a761dbc8e483"
Guid="7f34010c-9d32-ab9b-9b72-a761dbc8e483">

<File Id="F_7f34010c9d32ab9b9b72a761dbc8e483" Name="NUNITA~1.DLL"
LongName="NUnitAddin.TestRunner.Server.dll"
src="NUnitAddin.TestRunner.Server\bin\Debug\NUnitAddin.TestRunner.Server.dll
" />

</Component>

<Component Id="C_cf2d9a23bab91fa0d04faebd7b838cb0"
Guid="cf2d9a23-bab9-1fa0-d04f-aebd7b838cb0">

<File Id="F_cf2d9a23bab91fa0d04faebd7b838cb0" Name="NUNITA~1.DLL"
LongName="NUnitAddin.Services.dll"
src="NUnitAddin.Services\bin\Debug\NUnitAddin.Services.dll" />

</Component>

<Component Id="C_88e0487a3873e87e79b151e4f004a4b6"
Guid="88e0487a-3873-e87e-79b1-51e4f004a4b6">

<File Id="F_88e0487a3873e87e79b151e4f004a4b6" Name="App.ico"
LongName="App.ico" src="WebServices\App.ico" />

</Component>

<Component Id="C_0226e97e099f56c9459e8cc37f0f81fc"
Guid="0226e97e-099f-56c9-459e-8cc37f0f81fc">

<File Id="F_0226e97e099f56c9459e8cc37f0f81fc" Name="TESTRU~1.ASM"
LongName="TestRunner.asmx" src="WebServices\TestRunner.asmx" />

</Component>

<Component Id="C_abaed4346402a89d24af5227fce1a2a7"
Guid="abaed434-6402-a89d-24af-5227fce1a2a7">

<File Id="F_abaed4346402a89d24af5227fce1a2a7" Name="WEB~1.CON"
LongName="Web.config" src="WebServices\Web.config" />

</Component>

<Component Id="C_efd8794321b374a62aa46415f0d4d49f"
Guid="efd87943-21b3-74a6-2aa4-6415f0d4d49f">

<File Id="F_efd8794321b374a62aa46415f0d4d49f" Name="NUNITA~1.DLL"
LongName="NUnitAddIn.WebServices.dll"
src="WebServices\bin\NUnitAddIn.WebServices.dll" />

</Component>

<Component Id="C_fd9a11e3d4055031bae078fd126e12a9"
Guid="fd9a11e3-d405-5031-bae0-78fd126e12a9">

<File Id="F_fd9a11e3d4055031bae078fd126e12a9" Name="NUNITA~1.DLL"
LongName="NUnitAddin.Tests.dll" src="bin\Debug\NUnitAddin.Tests.dll" />

</Component>

<Component Id="C_cdb5b4cd6f1c302d0c477730dce4198c"
Guid="cdb5b4cd-6f1c-302d-0c47-7730dce4198c">

<File Id="F_cdb5b4cd6f1c302d0c477730dce4198c" Name="NUNITA~1.DLL"
LongName="NUnitAddin.Tools.dll"
src="NUnitAddin.Tools\bin\Debug\NUnitAddin.Tools.dll" />

</Component>

<Component Id="C_c0039f0449819281a564efaf1b127a46"
Guid="c0039f04-4981-9281-a564-efaf1b127a46">

<File Id="F_c0039f0449819281a564efaf1b127a46" Name="PROCES~1.EXE"
LongName="ProcessInvocation.exe"
src="ProcessInvocation\bin\ProcessInvocation.exe" />

</Component>

</Directory>

</Directory>

</Module>

</Wix>

_____

From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Riko Eksteen
Sent: 05 May 2004 10:15
To: ***@users.sourceforge.net; Anand Murugesan;
wix-***@lists.sourceforge.net
Subject: RE: [WiX-users] Including all files under a directory

I finally understand why the FileGroup element is so dangerous, and I won't
be using it again (thanks Rob).

I had a look at the component rules in the SDK again, and realised that the
requirements there doesn't fit with FileGroup. Specifically, one should
never add or remove resources from a component without changing the
component code, otherwise those resources might not be
removed/repaired/upgraded etc. Think this is pretty self-evident. If that is
the case, "The <FileGroup/> element is a very dangerous thing to use"
because if files in a folder are included this way, there is no way to know
whether you actually add new resources to an already existing component.

That sent me an a mission to find out how InstallShield's dynamic file
linking works, because it would be subject to the same flaw in logic, so to
speak. InstallShield's dynamic linking includes both subfolders and files,
and what it actually does behind your back is to create new components per
subfolder, include all the files, and set the first as the KeyPath. It also
generates new component codes at build time, so that the above requirement
is met. So this would work, theoretically (we certainly haven't had

problems with it), but it does make it hard to keep track of what files
exactly are included in your components, and might lead to some problems
when doing upgrades.

Anyway, this brings me back to the right way to add files in WiX - manually.
This is fine and dandy, except that I've spent just about a whole day adding
every single xml file in the specific product (there 696 of these files and
212 related folders) and I'm still going. This is a bit of a problem: apart
from the fact that the text-based entry method is error prone, it will be a
hell of an ask to track changes and add them correctly. It is here that
InstallShield has a significant advantage.

I spoke to some of our developers yesterday and they are not very keen to
use something like this - they want an easier way to include files etc. So
now I feel like I'm back to square one - I don't want to use a product like
InstallShield, because 1) it's expensive to distribute all round 2) it does
stuff behind your back 3) it doesn't create the cleanest MSIs (unnecessary
tables etc.). I would like something that would allow the developers to
author and maintain their own MSIs, but Visual Studio Installer is too
high-level (hides everything away) and it looks like WiX will be difficult
to use for large projects, despite it's many advantages.

Any thoughts?

-----Original Message-----
From: Rob Mensching [mailto:***@users.sourceforge.net]
Sent: 04 May 2004 02:12
To: 'Anand Murugesan'; wix-***@lists.sourceforge.net
Subject: RE: [WiX-users] Including all files under a directory

The <FileGroup/> element is a very dangerous thing to use and I always
discourage its use. Autogenerating Components (which would be necessary to
add Files from subdirectories) isn't just dangerous, it is down right scary.
You have to understand the Component Rules
(http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx) and then you'll
see why autogenerating Components for each of your Directories is a really
scary thing to do.

The WiX toolset does not autogenerate Components. Full stop.

_____

From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Anand Murugesan
Sent: Monday, May 03, 2004 4:43 PM
To: wix-***@lists.sourceforge.net
Subject: [WiX-users] Including all files under a directory

Hi All,
I am trying to add all the files (including the subdirectories), under
C:\software\package1 into my MSI.
I am using the following MSI segment. But, it includes only the top level
files in the package1 directory. How do I make it to drill down to all
subdirectories ?
<FileGroup Prefix='bla' DiskId='1' src='C:\software\package1' />

Is this the right approach, or should I consider creating a separate
archieve or cab file and reference it in my wsx file. If thats the better
solution, how do I do that for the above mentioned scenario ?

Thanks,
Anand.

Zdravko Stoychev

2004-05-05 19:57:59 UTC

Permalink

Hi!

Actually I am coding a such tool already. Project is called WixTool and
Is hosted at sf.net too. It's still in pre-release stage, but one could
Edit project XML file, compile, run and uninstall it.

Anyone is free to join in.
:)

-----Original Message-----
From: "Orion Edwards" <***@coke.net.nz>
To: <wix-***@lists.sourceforge.net>
Subject: Re: [WiX-users] Including all files under a directory
Date: Thu, 6 May 2004 00:39:20 +1200

I spoke to some of our developers yesterday and they are not very keen =
to use something like this - they want an easier way to include files =
etc. So now I feel like I'm back to square one - I don't want to use a =
product like InstallShield, because 1) it's expensive to distribute all =
round 2) it does stuff behind your back 3) it doesn't create the =
cleanest MSIs (unnecessary tables etc.). I would like something that =
would allow the developers to author and maintain their own MSIs, but =
Visual Studio Installer is too high-level (hides everything away) and it =
looks like WiX will be difficult to use for large projects, despite it's =
many advantages.

Any thoughts?

I agree. I've got a lot of experience with Installshield and (imho) it's =
awful. Does god knows what in the background, which slows things down =
and adds complexity (more complexity =3D=3D more bugs). Don't even get =
me started on "Installscript" :-)

Terry Denham

2004-05-05 19:59:24 UTC

Permalink

Great idea Jamie and now I don't have to write one.

What I was going to do was use Guid.NewGuid() to create a new Guid when I
needed one. To solve the issue of when to create a new guid as I walked the
directory tree if a file wasn't already added as a component, then I would
add the file as a new component and then generate a Guid for the file when
I'm adding it to the Wix model.

Terry

To: "'Riko Eksteen'"
Subject: RE: [WiX-users] Including all files under a directory
Date: Wed, 5 May 2004 15:14:33 +0100
I've been working on a command line tool that updates the File, Directory
and Component elements in a WXS file based on the projects in a Visual
Studio solution. At the moment it copies all files with a 'Build Action'
of
'Content' and all project outputs for a specified solution configuration.
Each file gets its own File and Component element allowing with any
Directory elements as needed. The Component.Guid, Id and File.Id are based
on a hash of the relative path (I know the Component.Guid should be
combined
with something else!). It is very much a work in progress. Let me know
what I'm missing or doing wrong! Here is an example of what it outputs at
the moment.
(Here's a build of NUnitAddIn created using it)
http://weblogs.asp.net/nunitaddin/archive/2004/05/01/124453.aspx
Because it updates the WXS file rather than recreating I can add things
like
custom actions. Because the File.Id and ComponentId are a hash of the
project items relative path they will remain consistent between updates.
It
is everything under ModuleDir that has been generated.
Should File.KeyPath be set to 'yes'?
Should Component.Id be randomized on each update?
<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://schemas.microsoft.com/wix/2003/01/wi">
<Module Id="NUnitAddin.sln" Guid="5FA9934D3F3341BBB28C6026583BC45C"
Language="1033" Version="1.0.0.0">
<Package Id="3807327122724060A7423BF1DE5C7FA5" Description="From
solution 'NUnitAddin.sln'" Comments="Auto generated with Sln2Wix"
Manufacturer="Mutant Design" InstallerVersion="200" Compressed="yes" />
<InstallExecuteSequence>

<Custom Action="Install"

<Custom Action="Uninstall"
Before="MsiUnpublishAssemblies">$C_a14fc90fa19a9a5acdbea8f24e4cb8ef=2</Custo
m>
</InstallExecuteSequence>
<CustomAction Id="Install"
FileKey="F_a14fc90fa19a9a5acdbea8f24e4cb8ef"
ExeCommand="/install" Execute="immediate" />
<CustomAction Id="Uninstall"
FileKey="F_a14fc90fa19a9a5acdbea8f24e4cb8ef" ExeCommand="/uninstall"
Execute="immediate" />
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ModuleDir" Name=".">
<Directory Id="D_605c646ba3f747c9b24bb1a277193aa2" Name="icons"
LongName="icons">
<Component Id="C_61fbcd6caea5c8e88f720a55d9df8e02"
Guid="61fbcd6c-aea5-c8e8-8f72-0a55d9df8e02">
<File Id="F_61fbcd6caea5c8e88f720a55d9df8e02" Name="Debug.ico"
LongName="Debug.ico" src="NUnitAddin\icons\Debug.ico" />
</Component>
<Component Id="C_a8db7eb234f62c179194d360ada47525"
Guid="a8db7eb2-34f6-2c17-9194-d360ada47525">
<File Id="F_a8db7eb234f62c179194d360ada47525" Name="NUnit.ico"
LongName="NUnit.ico" src="NUnitAddin\icons\NUnit.ico" />
</Component>
<Component Id="C_be78b109c9f515e5a360bcd79a4822ea"
Guid="be78b109-c9f5-15e5-a360-bcd79a4822ea">
<File Id="F_be78b109c9f515e5a360bcd79a4822ea"
Name="Runtime.ico"
LongName="Runtime.ico" src="NUnitAddin\icons\Runtime.ico" />
</Component>
<Component Id="C_0fa6f464d88f67139a06edd87e5c5c0e"
Guid="0fa6f464-d88f-6713-9a06-edd87e5c5c0e">
<File Id="F_0fa6f464d88f67139a06edd87e5c5c0e"
Name="VISUAL~1.ICO" LongName="VisualStudio.ico"
src="NUnitAddin\icons\VisualStudio.ico" />
</Component>
</Directory>
<Directory Id="D_577b9fd8db914fc3b27da51091ab143b" Name="runtimes"
LongName="runtimes">
<Component Id="C_d02d696b9530b17f7c0fb25fbc756d19"
Guid="d02d696b-9530-b17f-7c0f-b25fbc756d19">
<File Id="F_d02d696b9530b17f7c0fb25fbc756d19"
Name="CDP_AP~1.CON" LongName="CDP_Apartment.config"
src="NUnitAddin\runtimes\CDP_Apartment.config" />
</Component>
<Component Id="C_992d17046bcf574f67a260aba454b637"
Guid="992d1704-6bcf-574f-67a2-60aba454b637">
<File Id="F_992d17046bcf574f67a260aba454b637"
Name="CDP_MA~1.CON" LongName="CDP_Marshaling.config"
src="NUnitAddin\runtimes\CDP_Marshaling.config" />
</Component>
<Component Id="C_3626c8bac9756919f631b830d6213c85"
Guid="3626c8ba-c975-6919-f631-b830d6213c85">
<File Id="F_3626c8bac9756919f631b830d6213c85"
Name="MONO~1.CON"
LongName="mono.config" src="NUnitAddin\runtimes\mono.config" />
</Component>
<Component Id="C_4b2fb538595fafa3207fb503cbcc730c"
Guid="4b2fb538-595f-afa3-207f-b503cbcc730c">
<File Id="F_4b2fb538595fafa3207fb503cbcc730c"
Name="NET10~1.CON"
LongName="net10.config" src="NUnitAddin\runtimes\net10.config" />
</Component>
<Component Id="C_14eb7860f8128506c36a706e0e14a193"
Guid="14eb7860-f812-8506-c36a-706e0e14a193">
<File Id="F_14eb7860f8128506c36a706e0e14a193"
Name="NET11~1.CON"
LongName="net11.config" src="NUnitAddin\runtimes\net11.config" />
</Component>
<Component Id="C_076902cce67640035c94c11cde5c617c"
Guid="076902cc-e676-4003-5c94-c11cde5c617c">
<File Id="F_076902cce67640035c94c11cde5c617c"
Name="NET12~1.CON"
LongName="net12.config" src="NUnitAddin\runtimes\net12.config" />
</Component>
<Component Id="C_97fbf17a2993af20f32712832b5fbcc7"
Guid="97fbf17a-2993-af20-f327-12832b5fbcc7">
<File Id="F_97fbf17a2993af20f32712832b5fbcc7"
Name="NET20~1.CON"
LongName="net20.config" src="NUnitAddin\runtimes\net20.config" />
</Component>
</Directory>
<Directory Id="D_e8a17bec33054952bb6f31dbdb2e7a81" Name="lib"
LongName="lib">
<Component Id="C_d68012501a3e4796a09f43b0208902b1"
Guid="d6801250-1a3e-4796-a09f-43b0208902b1">
<File Id="F_d68012501a3e4796a09f43b0208902b1"
Name="MUTANT~3.DLL" LongName="MutantDesign.ManagedAddIns.dll"
src="..\ManagedAddIns\Tests\bin\MutantDesign.ManagedAddIns.dll" />
</Component>
<Component Id="C_79ba08747349da554584d763e9c3b536"
Guid="79ba0874-7349-da55-4584-d763e9c3b536">
<File Id="F_79ba08747349da554584d763e9c3b536"
Name="MUTANT~3.DLL" LongName="MutantDesign.ManagedAddIns.Services.dll"
src="..\ManagedAddIns\Tests\bin\MutantDesign.ManagedAddIns.Services.dll" />
</Component>
</Directory>
<Component Id="C_0d57b7d4022f1f0ee5cf9f3dc3e40020"
Guid="0d57b7d4-022f-1f0e-e5cf-9f3dc3e40020">
<File Id="F_0d57b7d4022f1f0ee5cf9f3dc3e40020"
Name="MUTANT~1.DLL"
LongName="MutantDesign.ManagedAddIns.Services.dll"
src="NUnitAddin\..\..\ManagedAddIns\Tests\bin\MutantDesign.ManagedAddIns.Ser
vices.dll" />
</Component>
<Component Id="C_fdfe27ba7225eefb183c7fa00e00c9b4"
Guid="fdfe27ba-7225-eefb-183c-7fa00e00c9b4">
<File Id="F_fdfe27ba7225eefb183c7fa00e00c9b4" Name="Notes.htm"
LongName="Notes.htm" src="NUnitAddin\Notes.htm" />
</Component>
<Component Id="C_43a46a698b77ff2ea398a9c3ce6f717f"
Guid="43a46a69-8b77-ff2e-a398-a9c3ce6f717f">
<File Id="F_43a46a698b77ff2ea398a9c3ce6f717f"
Name="NUNITA~1.CON"
LongName="nunitaddin.config" src="NUnitAddin\nunitaddin.config" />
</Component>
<Component Id="C_a14fc90fa19a9a5acdbea8f24e4cb8ef"
Guid="a14fc90f-a19a-9a5a-cdbe-a8f24e4cb8ef">
<File Id="F_a14fc90fa19a9a5acdbea8f24e4cb8ef"
Name="NUNITA~1.EXE"
LongName="NUnitAddin.exe" src="NUnitAddin\bin\Debug\NUnitAddin.exe" />
</Component>
<Component Id="C_d1f9216d472c9165285a3517afc5c8c6"
Guid="d1f9216d-472c-9165-285a-3517afc5c8c6">
<File Id="F_d1f9216d472c9165285a3517afc5c8c6"
Name="NUNITA~2.CON"
LongName="NUnitAddin.exe.config"
src="NUnitAddin\bin\Debug\NUnitAddin.exe.config" />
</Component>
<Component Id="C_4c92e542556b64cb5e7ced616636c9bd"
Guid="4c92e542-556b-64cb-5e7c-ed616636c9bd">
<File Id="F_4c92e542556b64cb5e7ced616636c9bd"
Name="MUTANT~1.DLL"
LongName="MutantDesign.dll" src="MutantDesign\bin\Debug\MutantDesign.dll"
/>
</Component>
<Component Id="C_bbbb3733bacceab10740626158732f7a"
Guid="bbbb3733-bacc-eab1-0740-626158732f7a">
<File Id="F_bbbb3733bacceab10740626158732f7a"
Name="MUTANT~1.DLL"
LongName="MutantDesign.EnvDte.dll"
src="MutantDesign.EnvDte\bin\Debug\MutantDesign.EnvDte.dll" />
</Component>
<Component Id="C_c26efcbb5aa7ad9545db861cc3e188fd"
Guid="c26efcbb-5aa7-ad95-45db-861cc3e188fd">
<File Id="F_c26efcbb5aa7ad9545db861cc3e188fd"
Name="NUNITA~1.DLL"
LongName="NUnitAddin.TestRunner.dll"
src="NUnitAddin.TestRunner\bin\Debug\NUnitAddin.TestRunner.dll" />
</Component>
<Component Id="C_cea1597c41a7fc9d2a6ad6174ed3829f"
Guid="cea1597c-41a7-fc9d-2a6a-d6174ed3829f">
<File Id="F_cea1597c41a7fc9d2a6ad6174ed3829f"
Name="NUNITA~1.DLL"
LongName="NUnitAddin.TestRunner.Framework.dll"
src="NUnitAddin.TestRunner.Framework\bin\Debug\NUnitAddin.TestRunner.Framewo
rk.dll" />
</Component>
<Component Id="C_dd1cc65557fa1b0aad383b8241a69d08"
Guid="dd1cc655-57fa-1b0a-ad38-3b8241a69d08">
<File Id="F_dd1cc65557fa1b0aad383b8241a69d08"
Name="NUNITA~1.DLL"
LongName="NUnitAddin.TestRunner.Runtimes.dll"
src="NUnitAddin.TestRunner.Runtimes\bin\Debug\NUnitAddin.TestRunner.Runtimes
.dll" />
</Component>
<Component Id="C_336119253d86417257327f18a666614f"
Guid="33611925-3d86-4172-5732-7f18a666614f">
<File Id="F_336119253d86417257327f18a666614f"
Name="NUNITA~1.DLL"
LongName="NUnitAddin.AdHoc.dll"
src="NUnitAddin.AdHoc\bin\Debug\NUnitAddin.AdHoc.dll" />
</Component>
<Component Id="C_c4fbba73ae9ea15c7c8da7260d564159"
Guid="c4fbba73-ae9e-a15c-7c8d-a7260d564159">
<File Id="F_c4fbba73ae9ea15c7c8da7260d564159"
Name="NUNITC~1.DLL"
LongName="nunit.core.dll"
src="NUnitAddin.NUnit\..\bin\NUnit\nunit.core.dll"
/>
</Component>
<Component Id="C_7d8d4deb750f1cdb13877abcd095bcd7"
Guid="7d8d4deb-750f-1cdb-1387-7abcd095bcd7">
<File Id="F_7d8d4deb750f1cdb13877abcd095bcd7"
Name="NUNITF~1.DLL"
LongName="nunit.framework.dll"
src="NUnitAddin.NUnit\..\bin\NUnit\nunit.framework.dll" />
</Component>
<Component Id="C_70d92e0fa3048fcbc862c509bf833e4c"
Guid="70d92e0f-a304-8fcb-c862-c509bf833e4c">
<File Id="F_70d92e0fa3048fcbc862c509bf833e4c"
Name="NUNITU~1.DLL"
LongName="nunit.uikit.dll"
src="NUnitAddin.NUnit\..\bin\NUnit\nunit.uikit.dll" />
</Component>
<Component Id="C_2676255db2265d5b5701d20b35c1da89"
Guid="2676255d-b226-5d5b-5701-d20b35c1da89">
<File Id="F_2676255db2265d5b5701d20b35c1da89"
Name="NUNITU~1.DLL"
LongName="nunit.util.dll"
src="NUnitAddin.NUnit\..\bin\NUnit\nunit.util.dll"
/>
</Component>
<Component Id="C_b88e98ae33aebcedf8500d6283320836"
Guid="b88e98ae-33ae-bced-f850-0d6283320836">
<File Id="F_b88e98ae33aebcedf8500d6283320836"
Name="NUNIT-~1.EXE"
LongName="nunit-console.exe"
src="NUnitAddin.NUnit\..\bin\NUnit\nunit-console.exe" />
</Component>
<Component Id="C_6b3a3e57c4a46a6851e05d8ed4020963"
Guid="6b3a3e57-c4a4-6a68-51e0-5d8ed4020963">
<File Id="F_6b3a3e57c4a46a6851e05d8ed4020963"
Name="NUNIT-~1.EXE"
LongName="nunit-gui.exe" src="NUnitAddin.NUnit\..\bin\NUnit\nunit-gui.exe"
/>
</Component>
<Component Id="C_a05778b889dc8f8bc2db9a3ec575f23a"
Guid="a05778b8-89dc-8f8b-c2db-9a3ec575f23a">
<File Id="F_a05778b889dc8f8bc2db9a3ec575f23a"
Name="NUNITA~1.DLL"
LongName="NUnitAddin.NUnit.dll"
src="NUnitAddin.NUnit\bin\Debug\NUnitAddin.NUnit.dll" />
</Component>
<Component Id="C_7f34010c9d32ab9b9b72a761dbc8e483"
Guid="7f34010c-9d32-ab9b-9b72-a761dbc8e483">
<File Id="F_7f34010c9d32ab9b9b72a761dbc8e483"
Name="NUNITA~1.DLL"
LongName="NUnitAddin.TestRunner.Server.dll"
src="NUnitAddin.TestRunner.Server\bin\Debug\NUnitAddin.TestRunner.Server.dll
" />
</Component>
<Component Id="C_cf2d9a23bab91fa0d04faebd7b838cb0"
Guid="cf2d9a23-bab9-1fa0-d04f-aebd7b838cb0">
<File Id="F_cf2d9a23bab91fa0d04faebd7b838cb0"
Name="NUNITA~1.DLL"
LongName="NUnitAddin.Services.dll"
src="NUnitAddin.Services\bin\Debug\NUnitAddin.Services.dll" />
</Component>
<Component Id="C_88e0487a3873e87e79b151e4f004a4b6"
Guid="88e0487a-3873-e87e-79b1-51e4f004a4b6">
<File Id="F_88e0487a3873e87e79b151e4f004a4b6" Name="App.ico"
LongName="App.ico" src="WebServices\App.ico" />
</Component>
<Component Id="C_0226e97e099f56c9459e8cc37f0f81fc"
Guid="0226e97e-099f-56c9-459e-8cc37f0f81fc">
<File Id="F_0226e97e099f56c9459e8cc37f0f81fc"
Name="TESTRU~1.ASM"
LongName="TestRunner.asmx" src="WebServices\TestRunner.asmx" />
</Component>
<Component Id="C_abaed4346402a89d24af5227fce1a2a7"
Guid="abaed434-6402-a89d-24af-5227fce1a2a7">
<File Id="F_abaed4346402a89d24af5227fce1a2a7" Name="WEB~1.CON"
LongName="Web.config" src="WebServices\Web.config" />
</Component>
<Component Id="C_efd8794321b374a62aa46415f0d4d49f"
Guid="efd87943-21b3-74a6-2aa4-6415f0d4d49f">
<File Id="F_efd8794321b374a62aa46415f0d4d49f"
Name="NUNITA~1.DLL"
LongName="NUnitAddIn.WebServices.dll"
src="WebServices\bin\NUnitAddIn.WebServices.dll" />
</Component>
<Component Id="C_fd9a11e3d4055031bae078fd126e12a9"
Guid="fd9a11e3-d405-5031-bae0-78fd126e12a9">
<File Id="F_fd9a11e3d4055031bae078fd126e12a9"
Name="NUNITA~1.DLL"
LongName="NUnitAddin.Tests.dll" src="bin\Debug\NUnitAddin.Tests.dll" />
</Component>
<Component Id="C_cdb5b4cd6f1c302d0c477730dce4198c"
Guid="cdb5b4cd-6f1c-302d-0c47-7730dce4198c">
<File Id="F_cdb5b4cd6f1c302d0c477730dce4198c"
Name="NUNITA~1.DLL"
LongName="NUnitAddin.Tools.dll"
src="NUnitAddin.Tools\bin\Debug\NUnitAddin.Tools.dll" />
</Component>
<Component Id="C_c0039f0449819281a564efaf1b127a46"
Guid="c0039f04-4981-9281-a564-efaf1b127a46">
<File Id="F_c0039f0449819281a564efaf1b127a46"
Name="PROCES~1.EXE"
LongName="ProcessInvocation.exe"
src="ProcessInvocation\bin\ProcessInvocation.exe" />
</Component>
</Directory>
</Directory>
</Module>
</Wix>
_____
Sent: 05 May 2004 10:15
Subject: RE: [WiX-users] Including all files under a directory
I finally understand why the FileGroup element is so dangerous, and I won't
be using it again (thanks Rob).
I had a look at the component rules in the SDK again, and realised that the
requirements there doesn't fit with FileGroup. Specifically, one should
never add or remove resources from a component without changing the
component code, otherwise those resources might not be
removed/repaired/upgraded etc. Think this is pretty self-evident. If that
is
the case, "The <FileGroup/> element is a very dangerous thing to use"
because if files in a folder are included this way, there is no way to know
whether you actually add new resources to an already existing component.
That sent me an a mission to find out how InstallShield's dynamic file
linking works, because it would be subject to the same flaw in logic, so to
speak. InstallShield's dynamic linking includes both subfolders and files,
and what it actually does behind your back is to create new components per
subfolder, include all the files, and set the first as the KeyPath. It also
generates new component codes at build time, so that the above requirement
is met. So this would work, theoretically (we certainly haven't had
problems with it), but it does make it hard to keep track of what files
exactly are included in your components, and might lead to some problems
when doing upgrades.
Anyway, this brings me back to the right way to add files in WiX -
manually.
This is fine and dandy, except that I've spent just about a whole day
adding
every single xml file in the specific product (there 696 of these files and
212 related folders) and I'm still going. This is a bit of a problem: apart
from the fact that the text-based entry method is error prone, it will be a
hell of an ask to track changes and add them correctly. It is here that
InstallShield has a significant advantage.
I spoke to some of our developers yesterday and they are not very keen to
use something like this - they want an easier way to include files etc. So
now I feel like I'm back to square one - I don't want to use a product like
InstallShield, because 1) it's expensive to distribute all round 2) it does
stuff behind your back 3) it doesn't create the cleanest MSIs (unnecessary
tables etc.). I would like something that would allow the developers to
author and maintain their own MSIs, but Visual Studio Installer is too
high-level (hides everything away) and it looks like WiX will be difficult
to use for large projects, despite it's many advantages.
Any thoughts?
-----Original Message-----
Sent: 04 May 2004 02:12
Subject: RE: [WiX-users] Including all files under a directory
The <FileGroup/> element is a very dangerous thing to use and I always
discourage its use. Autogenerating Components (which would be necessary to
add Files from subdirectories) isn't just dangerous, it is down right
scary.
You have to understand the Component Rules
(http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx) and then
you'll
see why autogenerating Components for each of your Directories is a really
scary thing to do.
The WiX toolset does not autogenerate Components. Full stop.
_____
Sent: Monday, May 03, 2004 4:43 PM
Subject: [WiX-users] Including all files under a directory
Hi All,
I am trying to add all the files (including the subdirectories), under
C:\software\package1 into my MSI.
I am using the following MSI segment. But, it includes only the top level
files in the package1 directory. How do I make it to drill down to all
subdirectories ?
<FileGroup Prefix='bla' DiskId='1' src='C:\software\package1' />
Is this the right approach, or should I consider creating a separate
archieve or cab file and reference it in my wsx file. If thats the better
solution, how do I do that for the above mentioned scenario ?
Thanks,
Anand.

Riko Eksteen

2004-05-06 07:35:15 UTC

Permalink

After about a day using WiX (coding XML in a text editor) I found that I had to generate new GUIDs frequently, so I wrote a little EXE that sits in your system tray and pastes a new GUID to the clipboard when you double click on it.

If anyone's interested, just shout. Of course for automated builds something like this won't be very useful. But still...

-----Original Message-----
From: Terry Denham [mailto:***@hotmail.com]
Sent: 05 May 2004 21:59
To: ***@familiar.co.uk; Riko Eksteen;
***@users.sourceforge.net; ***@Sun.COM;
wix-***@lists.sourceforge.net
Subject: RE: [WiX-users] Including all files under a directory

Great idea Jamie and now I don't have to write one.

What I was going to do was use Guid.NewGuid() to create a new Guid when I
needed one. To solve the issue of when to create a new guid as I walked the
directory tree if a file wasn't already added as a component, then I would
add the file as a new component and then generate a Guid for the file when
I'm adding it to the Wix model.

Terry

Steve Christensen

2004-05-06 17:50:36 UTC

Permalink

Post by Riko Eksteen
After about a day using WiX (coding XML in a text editor) I found that
I had to generate new GUIDs frequently, so I wrote a little EXE that
sits in your system tray and pastes a new GUID to the clipboard when
you double click on it.
If anyone's interested, just shout. Of course for automated builds
something like this won't be very useful. But still...

Would it make any sense to include GUID creation through the candle
preprocessor? (and would Rob and the other developers be amenable to
it?)

Something like:

...
<?define MyServerGuid=$(CreateGuid)?>
...
<Component Id="MyServer" Guid="$(var.MyServerGuid)">
...
</Component>
...

I'm doing something like it now as part of an automated build to create
a new package code for each build. I'm having our build tool pass the
version string and package code on the candle command line (-d). But,
the command-line is going to get very long when I start passing
component GUIDs as well.

-Steve

Orion Edwards

2004-05-07 00:12:14 UTC

Permalink

I already submitted a patch for candle to add the $(guid) variable which is
replaced with a generated GUID every time it is processed.

Note that if you leave out the Package code, wix auto generates it, but this is
the only place where it happens. I auto generate Product codes so am using my
patched version of candle, but for most scenarios this is not a good thing (ie:
generating completely different component codes every time you build the MSI
may not be good.)

As for passing in component guids on the command line, why not just have an
include file full of defines, which you can store and edit as you please.

Post by Steve Christensen

Shaun Wilde

2004-05-06 14:44:31 UTC

Permalink

This are my visual studio macros

Imports EnvDTE
Imports System.Diagnostics

Public Module WXSHelpers

Sub InsertGuid()
DTE.ActiveDocument.Selection.Text =
System.Guid.NewGuid.ToString.Replace("-", "").ToUpper
End Sub

Sub InsertGuidWithLeadingUnderscore()
DTE.ActiveDocument.Selection.Text = "_" &
System.Guid.NewGuid.ToString.Replace("-", "").ToUpper
End Sub

Sub InsertHyphenedGuid()
DTE.ActiveDocument.Selection.Text =
System.Guid.NewGuid.ToString.ToUpper
End Sub

End Module

Just attach to some buttons on a toolbar and voila

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Riko Eksteen
Sent: 06 May 2004 08:35
To: wix-***@lists.sourceforge.net
Subject: RE: [WiX-users] Including all files under a directory

After about a day using WiX (coding XML in a text editor) I found that I had
to generate new GUIDs frequently, so I wrote a little EXE that sits in your
system tray and pastes a new GUID to the clipboard when you double click on
it.

If anyone's interested, just shout. Of course for automated builds something
like this won't be very useful. But still...

-----Original Message-----
From: Terry Denham [mailto:***@hotmail.com]
Sent: 05 May 2004 21:59
To: ***@familiar.co.uk; Riko Eksteen;
***@users.sourceforge.net; ***@Sun.COM;
wix-***@lists.sourceforge.net
Subject: RE: [WiX-users] Including all files under a directory

Great idea Jamie and now I don't have to write one.

What I was going to do was use Guid.NewGuid() to create a new Guid when I
needed one. To solve the issue of when to create a new guid as I walked the
directory tree if a file wasn't already added as a component, then I would
add the file as a new component and then generate a Guid for the file when
I'm adding it to the Wix model.

Terry

Action'

of
'Content' and all project outputs for a specified solution configuration.
Each file gets its own File and Component element allowing with any
Directory elements as needed. The Component.Guid, Id and File.Id are
based on a hash of the relative path (I know the Component.Guid should
be combined with something else!). It is very much a work in progress.
Let me know what I'm missing or doing wrong! Here is an example of
what it outputs at the moment.
(Here's a build of NUnitAddIn created using it)
http://weblogs.asp.net/nunitaddin/archive/2004/05/01/124453.aspx
Because it updates the WXS file rather than recreating I can add things
like custom actions. Because the File.Id and ComponentId are a hash of
the project items relative path they will remain consistent between
updates.
It
is everything under ModuleDir that has been generated.
Should File.KeyPath be set to 'yes'?
Should Component.Id be randomized on each update?
<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://schemas.microsoft.com/wix/2003/01/wi">
<Module Id="NUnitAddin.sln" Guid="5FA9934D3F3341BBB28C6026583BC45C"
Language="1033" Version="1.0.0.0">
<Package Id="3807327122724060A7423BF1DE5C7FA5" Description="From
solution 'NUnitAddin.sln'" Comments="Auto generated with Sln2Wix"
Manufacturer="Mutant Design" InstallerVersion="200" Compressed="yes" />
<InstallExecuteSequence>

<Custom Action="Install"
m>

<Custom Action="Uninstall"
Before="MsiUnpublishAssemblies">$C_a14fc90fa19a9a5acdbea8f24e4cb8ef=2</
Custo
m>
</InstallExecuteSequence>
<CustomAction Id="Install"
FileKey="F_a14fc90fa19a9a5acdbea8f24e4cb8ef"
ExeCommand="/install" Execute="immediate" />
<CustomAction Id="Uninstall"
FileKey="F_a14fc90fa19a9a5acdbea8f24e4cb8ef" ExeCommand="/uninstall"
Execute="immediate" />
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ModuleDir" Name=".">
<Directory Id="D_605c646ba3f747c9b24bb1a277193aa2" Name="icons"
LongName="icons">
<Component Id="C_61fbcd6caea5c8e88f720a55d9df8e02"
Guid="61fbcd6c-aea5-c8e8-8f72-0a55d9df8e02">
<File Id="F_61fbcd6caea5c8e88f720a55d9df8e02" Name="Debug.ico"
LongName="Debug.ico" src="NUnitAddin\icons\Debug.ico" />
</Component>
<Component Id="C_a8db7eb234f62c179194d360ada47525"
Guid="a8db7eb2-34f6-2c17-9194-d360ada47525">
<File Id="F_a8db7eb234f62c179194d360ada47525" Name="NUnit.ico"
LongName="NUnit.ico" src="NUnitAddin\icons\NUnit.ico" />
</Component>
<Component Id="C_be78b109c9f515e5a360bcd79a4822ea"
Guid="be78b109-c9f5-15e5-a360-bcd79a4822ea">
<File Id="F_be78b109c9f515e5a360bcd79a4822ea"
Name="Runtime.ico"
LongName="Runtime.ico" src="NUnitAddin\icons\Runtime.ico" />
</Component>
<Component Id="C_0fa6f464d88f67139a06edd87e5c5c0e"
Guid="0fa6f464-d88f-6713-9a06-edd87e5c5c0e">
<File Id="F_0fa6f464d88f67139a06edd87e5c5c0e"
Name="VISUAL~1.ICO" LongName="VisualStudio.ico"
src="NUnitAddin\icons\VisualStudio.ico" />
</Component>
</Directory>
<Directory Id="D_577b9fd8db914fc3b27da51091ab143b" Name="runtimes"
LongName="runtimes">
<Component Id="C_d02d696b9530b17f7c0fb25fbc756d19"
Guid="d02d696b-9530-b17f-7c0f-b25fbc756d19">
<File Id="F_d02d696b9530b17f7c0fb25fbc756d19"
Name="CDP_AP~1.CON" LongName="CDP_Apartment.config"
src="NUnitAddin\runtimes\CDP_Apartment.config" />
</Component>
<Component Id="C_992d17046bcf574f67a260aba454b637"
Guid="992d1704-6bcf-574f-67a2-60aba454b637">
<File Id="F_992d17046bcf574f67a260aba454b637"
Name="CDP_MA~1.CON" LongName="CDP_Marshaling.config"
src="NUnitAddin\runtimes\CDP_Marshaling.config" />
</Component>
<Component Id="C_3626c8bac9756919f631b830d6213c85"
Guid="3626c8ba-c975-6919-f631-b830d6213c85">
<File Id="F_3626c8bac9756919f631b830d6213c85"
Name="MONO~1.CON"
LongName="mono.config" src="NUnitAddin\runtimes\mono.config" />
</Component>
<Component Id="C_4b2fb538595fafa3207fb503cbcc730c"
Guid="4b2fb538-595f-afa3-207f-b503cbcc730c">
<File Id="F_4b2fb538595fafa3207fb503cbcc730c"
Name="NET10~1.CON"
LongName="net10.config" src="NUnitAddin\runtimes\net10.config" />
</Component>
<Component Id="C_14eb7860f8128506c36a706e0e14a193"
Guid="14eb7860-f812-8506-c36a-706e0e14a193">
<File Id="F_14eb7860f8128506c36a706e0e14a193"
Name="NET11~1.CON"
LongName="net11.config" src="NUnitAddin\runtimes\net11.config" />
</Component>
<Component Id="C_076902cce67640035c94c11cde5c617c"
Guid="076902cc-e676-4003-5c94-c11cde5c617c">
<File Id="F_076902cce67640035c94c11cde5c617c"
Name="NET12~1.CON"
LongName="net12.config" src="NUnitAddin\runtimes\net12.config" />
</Component>
<Component Id="C_97fbf17a2993af20f32712832b5fbcc7"
Guid="97fbf17a-2993-af20-f327-12832b5fbcc7">
<File Id="F_97fbf17a2993af20f32712832b5fbcc7"
Name="NET20~1.CON"
LongName="net20.config" src="NUnitAddin\runtimes\net20.config" />
</Component>
</Directory>
<Directory Id="D_e8a17bec33054952bb6f31dbdb2e7a81" Name="lib"
LongName="lib">
<Component Id="C_d68012501a3e4796a09f43b0208902b1"
Guid="d6801250-1a3e-4796-a09f-43b0208902b1">
<File Id="F_d68012501a3e4796a09f43b0208902b1"
Name="MUTANT~3.DLL" LongName="MutantDesign.ManagedAddIns.dll"
src="..\ManagedAddIns\Tests\bin\MutantDesign.ManagedAddIns.dll" />
</Component>
<Component Id="C_79ba08747349da554584d763e9c3b536"
Guid="79ba0874-7349-da55-4584-d763e9c3b536">
<File Id="F_79ba08747349da554584d763e9c3b536"
Name="MUTANT~3.DLL" LongName="MutantDesign.ManagedAddIns.Services.dll"
src="..\ManagedAddIns\Tests\bin\MutantDesign.ManagedAddIns.Services.dll
" />
</Component>
</Directory>
<Component Id="C_0d57b7d4022f1f0ee5cf9f3dc3e40020"
Guid="0d57b7d4-022f-1f0e-e5cf-9f3dc3e40020">
<File Id="F_0d57b7d4022f1f0ee5cf9f3dc3e40020"
Name="MUTANT~1.DLL"
LongName="MutantDesign.ManagedAddIns.Services.dll"
src="NUnitAddin\..\..\ManagedAddIns\Tests\bin\MutantDesign.ManagedAddIn
s.Ser
vices.dll" />
</Component>
<Component Id="C_fdfe27ba7225eefb183c7fa00e00c9b4"
Guid="fdfe27ba-7225-eefb-183c-7fa00e00c9b4">
<File Id="F_fdfe27ba7225eefb183c7fa00e00c9b4" Name="Notes.htm"
LongName="Notes.htm" src="NUnitAddin\Notes.htm" />
</Component>
<Component Id="C_43a46a698b77ff2ea398a9c3ce6f717f"
Guid="43a46a69-8b77-ff2e-a398-a9c3ce6f717f">
<File Id="F_43a46a698b77ff2ea398a9c3ce6f717f"
Name="NUNITA~1.CON"
LongName="nunitaddin.config" src="NUnitAddin\nunitaddin.config" />
</Component>
<Component Id="C_a14fc90fa19a9a5acdbea8f24e4cb8ef"
Guid="a14fc90f-a19a-9a5a-cdbe-a8f24e4cb8ef">
<File Id="F_a14fc90fa19a9a5acdbea8f24e4cb8ef"
Name="NUNITA~1.EXE"
LongName="NUnitAddin.exe" src="NUnitAddin\bin\Debug\NUnitAddin.exe" />
</Component>
<Component Id="C_d1f9216d472c9165285a3517afc5c8c6"
Guid="d1f9216d-472c-9165-285a-3517afc5c8c6">
<File Id="F_d1f9216d472c9165285a3517afc5c8c6"
Name="NUNITA~2.CON"
LongName="NUnitAddin.exe.config"
src="NUnitAddin\bin\Debug\NUnitAddin.exe.config" />
</Component>
<Component Id="C_4c92e542556b64cb5e7ced616636c9bd"
Guid="4c92e542-556b-64cb-5e7c-ed616636c9bd">
<File Id="F_4c92e542556b64cb5e7ced616636c9bd"
Name="MUTANT~1.DLL"
LongName="MutantDesign.dll" src="MutantDesign\bin\Debug\MutantDesign.dll"
/>
</Component>
<Component Id="C_bbbb3733bacceab10740626158732f7a"
Guid="bbbb3733-bacc-eab1-0740-626158732f7a">
<File Id="F_bbbb3733bacceab10740626158732f7a"
Name="MUTANT~1.DLL"
LongName="MutantDesign.EnvDte.dll"
src="MutantDesign.EnvDte\bin\Debug\MutantDesign.EnvDte.dll" />
</Component>
<Component Id="C_c26efcbb5aa7ad9545db861cc3e188fd"
Guid="c26efcbb-5aa7-ad95-45db-861cc3e188fd">
<File Id="F_c26efcbb5aa7ad9545db861cc3e188fd"
Name="NUNITA~1.DLL"
LongName="NUnitAddin.TestRunner.dll"
src="NUnitAddin.TestRunner\bin\Debug\NUnitAddin.TestRunner.dll" />
</Component>
<Component Id="C_cea1597c41a7fc9d2a6ad6174ed3829f"
Guid="cea1597c-41a7-fc9d-2a6a-d6174ed3829f">
<File Id="F_cea1597c41a7fc9d2a6ad6174ed3829f"
Name="NUNITA~1.DLL"
LongName="NUnitAddin.TestRunner.Framework.dll"
src="NUnitAddin.TestRunner.Framework\bin\Debug\NUnitAddin.TestRunner.Fr
amewo
rk.dll" />
</Component>
<Component Id="C_dd1cc65557fa1b0aad383b8241a69d08"
Guid="dd1cc655-57fa-1b0a-ad38-3b8241a69d08">
<File Id="F_dd1cc65557fa1b0aad383b8241a69d08"
Name="NUNITA~1.DLL"
LongName="NUnitAddin.TestRunner.Runtimes.dll"
src="NUnitAddin.TestRunner.Runtimes\bin\Debug\NUnitAddin.TestRunner.Run
times
.dll" />
</Component>
<Component Id="C_336119253d86417257327f18a666614f"
Guid="33611925-3d86-4172-5732-7f18a666614f">
<File Id="F_336119253d86417257327f18a666614f"
Name="NUNITA~1.DLL"
LongName="NUnitAddin.AdHoc.dll"
src="NUnitAddin.AdHoc\bin\Debug\NUnitAddin.AdHoc.dll" />
</Component>
<Component Id="C_c4fbba73ae9ea15c7c8da7260d564159"
Guid="c4fbba73-ae9e-a15c-7c8d-a7260d564159">
<File Id="F_c4fbba73ae9ea15c7c8da7260d564159"
Name="NUNITC~1.DLL"
LongName="nunit.core.dll"
src="NUnitAddin.NUnit\..\bin\NUnit\nunit.core.dll"
/>
</Component>
<Component Id="C_7d8d4deb750f1cdb13877abcd095bcd7"
Guid="7d8d4deb-750f-1cdb-1387-7abcd095bcd7">
<File Id="F_7d8d4deb750f1cdb13877abcd095bcd7"
Name="NUNITF~1.DLL"
LongName="nunit.framework.dll"
src="NUnitAddin.NUnit\..\bin\NUnit\nunit.framework.dll" />
</Component>
<Component Id="C_70d92e0fa3048fcbc862c509bf833e4c"
Guid="70d92e0f-a304-8fcb-c862-c509bf833e4c">
<File Id="F_70d92e0fa3048fcbc862c509bf833e4c"
Name="NUNITU~1.DLL"
LongName="nunit.uikit.dll"
src="NUnitAddin.NUnit\..\bin\NUnit\nunit.uikit.dll" />
</Component>
<Component Id="C_2676255db2265d5b5701d20b35c1da89"
Guid="2676255d-b226-5d5b-5701-d20b35c1da89">
<File Id="F_2676255db2265d5b5701d20b35c1da89"
Name="NUNITU~1.DLL"
LongName="nunit.util.dll"
src="NUnitAddin.NUnit\..\bin\NUnit\nunit.util.dll"
/>
</Component>
<Component Id="C_b88e98ae33aebcedf8500d6283320836"
Guid="b88e98ae-33ae-bced-f850-0d6283320836">
<File Id="F_b88e98ae33aebcedf8500d6283320836"
Name="NUNIT-~1.EXE"
LongName="nunit-console.exe"
src="NUnitAddin.NUnit\..\bin\NUnit\nunit-console.exe" />
</Component>
<Component Id="C_6b3a3e57c4a46a6851e05d8ed4020963"
Guid="6b3a3e57-c4a4-6a68-51e0-5d8ed4020963">
<File Id="F_6b3a3e57c4a46a6851e05d8ed4020963"
Name="NUNIT-~1.EXE"
LongName="nunit-gui.exe" src="NUnitAddin.NUnit\..\bin\NUnit\nunit-gui.exe"
/>
</Component>
<Component Id="C_a05778b889dc8f8bc2db9a3ec575f23a"
Guid="a05778b8-89dc-8f8b-c2db-9a3ec575f23a">
<File Id="F_a05778b889dc8f8bc2db9a3ec575f23a"
Name="NUNITA~1.DLL"
LongName="NUnitAddin.NUnit.dll"
src="NUnitAddin.NUnit\bin\Debug\NUnitAddin.NUnit.dll" />
</Component>
<Component Id="C_7f34010c9d32ab9b9b72a761dbc8e483"
Guid="7f34010c-9d32-ab9b-9b72-a761dbc8e483">
<File Id="F_7f34010c9d32ab9b9b72a761dbc8e483"
Name="NUNITA~1.DLL"
LongName="NUnitAddin.TestRunner.Server.dll"
src="NUnitAddin.TestRunner.Server\bin\Debug\NUnitAddin.TestRunner.Serve
r.dll
" />
</Component>
<Component Id="C_cf2d9a23bab91fa0d04faebd7b838cb0"
Guid="cf2d9a23-bab9-1fa0-d04f-aebd7b838cb0">
<File Id="F_cf2d9a23bab91fa0d04faebd7b838cb0"
Name="NUNITA~1.DLL"
LongName="NUnitAddin.Services.dll"
src="NUnitAddin.Services\bin\Debug\NUnitAddin.Services.dll" />
</Component>
<Component Id="C_88e0487a3873e87e79b151e4f004a4b6"
Guid="88e0487a-3873-e87e-79b1-51e4f004a4b6">
<File Id="F_88e0487a3873e87e79b151e4f004a4b6" Name="App.ico"
LongName="App.ico" src="WebServices\App.ico" />
</Component>
<Component Id="C_0226e97e099f56c9459e8cc37f0f81fc"
Guid="0226e97e-099f-56c9-459e-8cc37f0f81fc">
<File Id="F_0226e97e099f56c9459e8cc37f0f81fc"
Name="TESTRU~1.ASM"
LongName="TestRunner.asmx" src="WebServices\TestRunner.asmx" />
</Component>
<Component Id="C_abaed4346402a89d24af5227fce1a2a7"
Guid="abaed434-6402-a89d-24af-5227fce1a2a7">
<File Id="F_abaed4346402a89d24af5227fce1a2a7" Name="WEB~1.CON"
LongName="Web.config" src="WebServices\Web.config" />
</Component>
<Component Id="C_efd8794321b374a62aa46415f0d4d49f"
Guid="efd87943-21b3-74a6-2aa4-6415f0d4d49f">
<File Id="F_efd8794321b374a62aa46415f0d4d49f"
Name="NUNITA~1.DLL"
LongName="NUnitAddIn.WebServices.dll"
src="WebServices\bin\NUnitAddIn.WebServices.dll" />
</Component>
<Component Id="C_fd9a11e3d4055031bae078fd126e12a9"
Guid="fd9a11e3-d405-5031-bae0-78fd126e12a9">
<File Id="F_fd9a11e3d4055031bae078fd126e12a9"
Name="NUNITA~1.DLL"
LongName="NUnitAddin.Tests.dll" src="bin\Debug\NUnitAddin.Tests.dll" />
</Component>
<Component Id="C_cdb5b4cd6f1c302d0c477730dce4198c"
Guid="cdb5b4cd-6f1c-302d-0c47-7730dce4198c">
<File Id="F_cdb5b4cd6f1c302d0c477730dce4198c"
Name="NUNITA~1.DLL"
LongName="NUnitAddin.Tools.dll"
src="NUnitAddin.Tools\bin\Debug\NUnitAddin.Tools.dll" />
</Component>
<Component Id="C_c0039f0449819281a564efaf1b127a46"
Guid="c0039f04-4981-9281-a564-efaf1b127a46">
<File Id="F_c0039f0449819281a564efaf1b127a46"
Name="PROCES~1.EXE"
LongName="ProcessInvocation.exe"
src="ProcessInvocation\bin\ProcessInvocation.exe" />
</Component>
</Directory>
</Directory>
</Module>
</Wix>
_____
Eksteen
Sent: 05 May 2004 10:15
Subject: RE: [WiX-users] Including all files under a directory
I finally understand why the FileGroup element is so dangerous, and I
won't be using it again (thanks Rob).
I had a look at the component rules in the SDK again, and realised that
the requirements there doesn't fit with FileGroup. Specifically, one
should never add or remove resources from a component without changing
the component code, otherwise those resources might not be
removed/repaired/upgraded etc. Think this is pretty self-evident. If
that is the case, "The <FileGroup/> element is a very dangerous thing
to use"
because if files in a folder are included this way, there is no way to
know whether you actually add new resources to an already existing

component.

That sent me an a mission to find out how InstallShield's dynamic file
linking works, because it would be subject to the same flaw in logic,
so to speak. InstallShield's dynamic linking includes both subfolders
and files, and what it actually does behind your back is to create new
components per subfolder, include all the files, and set the first as
the KeyPath. It also generates new component codes at build time, so
that the above requirement is met. So this would work, theoretically
(we certainly haven't had
problems with it), but it does make it hard to keep track of what files
exactly are included in your components, and might lead to some
problems when doing upgrades.
Anyway, this brings me back to the right way to add files in WiX -
manually.
This is fine and dandy, except that I've spent just about a whole day
adding every single xml file in the specific product (there 696 of
these files and
apart from the fact that the text-based entry method is error prone, it
will be a hell of an ask to track changes and add them correctly. It is
here that InstallShield has a significant advantage.
I spoke to some of our developers yesterday and they are not very keen
to use something like this - they want an easier way to include files
etc. So now I feel like I'm back to square one - I don't want to use a
product like InstallShield, because 1) it's expensive to distribute all
round 2) it does stuff behind your back 3) it doesn't create the
cleanest MSIs (unnecessary tables etc.). I would like something that
would allow the developers to author and maintain their own MSIs, but
Visual Studio Installer is too high-level (hides everything away) and
it looks like WiX will be difficult to use for large projects, despite it's

many advantages.

Any thoughts?
-----Original Message-----
Sent: 04 May 2004 02:12
Subject: RE: [WiX-users] Including all files under a directory
The <FileGroup/> element is a very dangerous thing to use and I always
discourage its use. Autogenerating Components (which would be
necessary to add Files from subdirectories) isn't just dangerous, it is
down right scary.
You have to understand the Component Rules
(http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx) and then
you'll see why autogenerating Components for each of your Directories
is a really scary thing to do.
The WiX toolset does not autogenerate Components. Full stop.
_____
Murugesan
Sent: Monday, May 03, 2004 4:43 PM
Subject: [WiX-users] Including all files under a directory
Hi All,
I am trying to add all the files (including the subdirectories), under
C:\software\package1 into my MSI.
I am using the following MSI segment. But, it includes only the top
level files in the package1 directory. How do I make it to drill down
to all subdirectories ?
<FileGroup Prefix='bla' DiskId='1' src='C:\software\package1' />
Is this the right approach, or should I consider creating a separate
archieve or cab file and reference it in my wsx file. If thats the
better solution, how do I do that for the above mentioned scenario ?
Thanks,
Anand.

-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software Learn developer
strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher
performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=dnemail3

Orion Edwards

2004-05-07 00:20:43 UTC

Permalink

Thanks a lot man. I've now got InsertHyphenedGuid() bound to ctrl+shift+g and
it's really useful :-)

Post by Shaun Wilde
This are my visual studio macros
Imports EnvDTE
Imports System.Diagnostics
Public Module WXSHelpers
Sub InsertGuid()
DTE.ActiveDocument.Selection.Text =
System.Guid.NewGuid.ToString.Replace("-", "").ToUpper
End Sub
Sub InsertGuidWithLeadingUnderscore()
DTE.ActiveDocument.Selection.Text = "_" &
System.Guid.NewGuid.ToString.Replace("-", "").ToUpper
End Sub
Sub InsertHyphenedGuid()
DTE.ActiveDocument.Selection.Text =
System.Guid.NewGuid.ToString.ToUpper
End Sub
End Module
Just attach to some buttons on a toolbar and voila

Terry Denham

2004-05-06 17:59:14 UTC

Permalink

Why do you need to create a new GUID for every build? This seems to be a
waste. A guid is only used to identify the component within the package but
if the file doensn't change location then I don't see any reason to regen
the guid, or am I missing something?

Terry

Post by Jason Swager
Subject: Re: [WiX-users] Including all files under a directory
Date: Thu, 6 May 2004 11:50:36 -0600

Would it make any sense to include GUID creation through the candle
preprocessor? (and would Rob and the other developers be amenable to
it?)
...
<?define MyServerGuid=$(CreateGuid)?>
...
<Component Id="MyServer" Guid="$(var.MyServerGuid)">
...
</Component>
...
I'm doing something like it now as part of an automated build to create
a new package code for each build. I'm having our build tool pass the
version string and package code on the candle command line (-d). But,
the command-line is going to get very long when I start passing
component GUIDs as well.
-Steve
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users

Steve Christensen

2004-05-06 22:52:11 UTC

Permalink

Post by Terry Denham
Why do you need to create a new GUID for every build? This seems to be a
waste. A guid is only used to identify the component within the package but
if the file doensn't change location then I don't see any reason to regen
the guid, or am I missing something?

Rob Mensching

2004-05-18 06:17:48 UTC

Permalink

Is your included file wrapped with <Include></Include? I think that is
necessary for files to get included. This needs to be documented. Thanks.

_____

From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of
***@ni.com
Sent: Tuesday, May 04, 2004 2:57 PM
To: wix-***@lists.sourceforge.net
Subject: [WiX-users] Do include files have to be in the same folder?

I am using build 2.0.1629.0. I don't think I saw this issue reported as a
bug... yet.
----------------------------------------------------------

I have a source file myProj.wxs

This file has the line <? include myShared.wxi ?>

If I have the file myShared.wxi in the same folder as myProj.wxs, everything
is dandy.

Now I move the shared file to c:\sharedIncludes\myShared.wxi

I just cant get things to work anymore . I changed the include line to have
the full path to the new location, tried using
$(var.sharedPath)\myShared.wxi, also tried the -i commandline switch. If I
get the path wrong candle complains that it cant find the file.

But if the path is correct, the include file is just silently ignored. The
stuff from the include file don't make it to the output. If I introduce
errors in the include file, still no complaints. Its just completely
ignored.

Anyone have any ideas?

Thanks
Naren

Rob Mensching

2004-05-18 06:28:50 UTC

Permalink

Okay, I've been wanting to get back to this feature for a while but I felt
it needed a good explanation.

I don't want to add a way to autogenerate GUIDs anywhere because I am
positive some developers will use it to generate their Component/@Guid
attributes. Doing so would be even worse than abusing the dreaded FileGroup
element.

Instead, Orion, I think we should target the scenario you're trying to hit
narrowly. So, I'm thinking maybe the right fix is to allow the Product/@Id
to be optional like the Package/@Id. If it is missing, it is autogenerated
for you. I'm still working through all the patching repercussions of this
type of behavior, but it seems like a decent tradeoff.

What do you think?

Also, do not continually generate the GUIDs for your Components. That is a
sure way to get completely hosed by the Component Rules. I obviously need
to write some more on this topic. <sigh/>

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Orion Edwards
Sent: Thursday, May 06, 2004 5:12 PM
To: Steve Christensen
Subject: Re: [WiX-users] Including all files under a directory

I already submitted a patch for candle to add the $(guid) variable which is
replaced with a generated GUID every time it is processed.

Note that if you leave out the Package code, wix auto generates it, but this
is
the only place where it happens. I auto generate Product codes so am using
my
patched version of candle, but for most scenarios this is not a good thing
(ie:
generating completely different component codes every time you build the MSI
may not be good.)

As for passing in component guids on the command line, why not just have an
include file full of defines, which you can store and edit as you please.

Post by Steve Christensen

-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=dnemail3

Orion Edwards

2004-05-18 22:16:45 UTC

Permalink

Post by Rob Mensching
I don't want to add a way to autogenerate GUIDs anywhere because I am
attributes. Doing so would be even worse than abusing the dreaded FileGroup
element.

Being aware of the component rules, I agree. - I'm not auto generating anything
except for the Product and Package Codes. Component GUIDs are all authored into
the script (that visual studio generate GUID macro is rather handy :-) )

Post by Rob Mensching
Instead, Orion, I think we should target the scenario you're trying to hit
for you. I'm still working through all the patching repercussions of this
type of behavior, but it seems like a decent tradeoff.

Fine by me, however I think that keeping the Id attribute mandatory in the
element and giving it some special value like -1 or "autogen" or something to
cause auto-generation may be a better idea, as an auto generated product code
is probably not the norm. Simply leaving things out to autogen them is a great
way to cause confusion and problems down the track if you ever have more than
one developer working on your installer(s).

Rob Mensching

2004-05-18 06:32:34 UTC

Permalink

1. As Orion noted, the Package/@Id is optional and if you remove it, it
will be autogenerated every build.

2. DO NOT change the Guids on your Components with every build. Steve, I
highly suggest reading through the Component Rules before going much
further. I have a blog entry on the topic here:
http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx that has links
to all the available information that I know of right now. I think I'm
going to have to try and write a cleaner version of all this since people
seem to be consistently confused.

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Steve
Christensen
Sent: Thursday, May 06, 2004 3:52 PM
To: Terry Denham
Cc: wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Including all files under a directory

Post by Terry Denham
Why do you need to create a new GUID for every build? This seems to be a
waste. A guid is only used to identify the component within the package

but

Post by Terry Denham
if the file doensn't change location then I don't see any reason to regen
the guid, or am I missing something?

If each automated build produces a new MSI file with non-identical
contents, doesn't that mean each MSI needs a unique PackageCode GUID?
When we're talking 4-5 MSIs as the products of every automated build, it
seems unrealistic to expect someone to update those GUIDs by hand.

Component GUIDs for data files packaged up with the application wouldn't
necessarily have to change, but shouldn't the components holding the
compiled applications/libraries change GUIDs more often, if not every
build?

Maybe I'm misreading the component documentation... I'm still very much
in the 'install scripting' mindset rather than the Windows Installer
mindset... If the system will only install a component if it hasn't
already been installed, doesn't that mean the component GUID needs to be
updated to ensure that the software produced by a particular build is
installed as one coherent piece?

-Steve

-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Steve Christensen

2004-05-25 17:40:06 UTC

Permalink

OK, I think I understand a bit better now about when the component GUIDs
need to change.

However, I do still have cases where I'm going to need to change every
component GUID with every automated build (the keypath is changing with
every build).

The path to the software installation is:
"<product name> + <version number> + <build number>"
(myproduct_v1.0.0_d845).

The build number changes with every build. Yes, that means the customer
can have multiple copies of the application on their system. That
allows them to install a new release during off-hours for acceptance
testing, but still maintain known-good build for training during the
day.

So, I'd definitely like an easy way to tell candle to generate a new
GUID for a Component, not just the Product/Package IDs. But I understand
if it is out-of-the-norm enough (or dangerous enough) that I'll need to
patch candle myself or have some other pre-processing mechanism to
generate the GUIDs.

-Steve

Post by Rob Mensching
will be autogenerated every build.
2. DO NOT change the Guids on your Components with every build. Steve, I
highly suggest reading through the Component Rules before going much
http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx that has links
to all the available information that I know of right now. I think I'm
going to have to try and write a cleaner version of all this since people
seem to be consistently confused.
-----Original Message-----
Christensen
Sent: Thursday, May 06, 2004 3:52 PM
To: Terry Denham
Subject: Re: [WiX-users] Including all files under a directory

Post by Terry Denham
Why do you need to create a new GUID for every build? This seems to be a
waste. A guid is only used to identify the component within the package

but

Post by Terry Denham
if the file doensn't change location then I don't see any reason to regen
the guid, or am I missing something?

If each automated build produces a new MSI file with non-identical
contents, doesn't that mean each MSI needs a unique PackageCode GUID?
When we're talking 4-5 MSIs as the products of every automated build, it
seems unrealistic to expect someone to update those GUIDs by hand.
Component GUIDs for data files packaged up with the application wouldn't
necessarily have to change, but shouldn't the components holding the
compiled applications/libraries change GUIDs more often, if not every
build?
Maybe I'm misreading the component documentation... I'm still very much
in the 'install scripting' mindset rather than the Windows Installer
mindset... If the system will only install a component if it hasn't
already been installed, doesn't that mean the component GUID needs to be
updated to ensure that the software produced by a particular build is
installed as one coherent piece?
-Steve
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users

Rob Mensching

2004-05-18 06:34:51 UTC

Permalink

I'm curious do those other install engines (NSIS and InnoSetup) transact the
changes to the user's machines?

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Steve
Christensen
Sent: Wednesday, May 05, 2004 11:27 AM
To: Orion Edwards
Cc: wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Including all files under a directory

Steve Christensen

2004-05-18 23:48:23 UTC

Permalink

Hi Rob,

I'm not sure what you're asking here. If it is in regards to my question
about using the md5 hashes to generate GUIDs, that was more dealing with
my having the wrong idea about component GUIDs.

NSIS does not use Windows Installer, and is strictly packaging /
scripting tool. As such, it does a decent job. My primary reasons for
picking it over Wise (either in its newer windows installer or older
versions) was that it allowed us to check-in a text file that everyone
could read and verify without a special editor. There are also no
licensing hurdles that stopped the developers from using it to package
up their own builds.

WiX also fits on both counts, which is why we're looking at it.

-Steve

Post by Rob Mensching
I'm curious do those other install engines (NSIS and InnoSetup) transact the
changes to the user's machines?
-----Original Message-----
Christensen
Sent: Wednesday, May 05, 2004 11:27 AM
To: Orion Edwards
Subject: Re: [WiX-users] Including all files under a directory

Rob Mensching

2004-05-18 06:36:34 UTC

Permalink

Jason, I'm thinking about removing <FileGroup/> and adding a tool that does
this sort of thing to the WiX toolset. I'm curious how this process has
worked out for you?

What you are doing here is the safest process that I've seen (considering
how restrictive the Component Rules are).

_____

From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Jason Swager
Sent: Wednesday, May 05, 2004 6:29 AM
To: wix-***@lists.sourceforge.net
Subject: RE: [WiX-users] Including all files under a directory

I've encountered the same issues; too many files to type into WIX. In our
case, we've currently got about 66,000 files per install. We don't put
every file in its own component, but it's still a massive amount of typing.
Prior to WIX, we were using WISE, which appears to have the same problems as
Install Shield and does things behind your back.

However, to at least make the initial work easier, we wrote a quick little
program that simply walks through specific directory and/or subdirectories,
building a partial WIX fragment as it goes. For every directory/file found,
it would expand the WIX fragment with the appropriate XML. Each file was
assigned a new component ID. After each fragment was built, a developer
would go and decide which files could be grouped into a single component,
and which ones would need to be on their own. That makes it MUCH easier to
maintain.

Jason

-----Original Message-----
From: Orion Edwards [mailto:***@coke.net.nz]
Sent: Wednesday, May 05, 2004 5:39 AM
To: wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Including all files under a directory

I spoke to some of our developers yesterday and they are not very keen to
use something like this - they want an easier way to include files etc. So
now I feel like I'm back to square one - I don't want to use a product like
InstallShield, because 1) it's expensive to distribute all round 2) it does
stuff behind your back 3) it doesn't create the cleanest MSIs (unnecessary
tables etc.). I would like something that would allow the developers to
author and maintain their own MSIs, but Visual Studio Installer is too
high-level (hides everything away) and it looks like WiX will be difficult
to use for large projects, despite it's many advantages.

Any thoughts?

I agree. I've got a lot of experience with Installshield and (imho) it's
awful. Does god knows what in the background, which slows things down and
adds complexity (more complexity == more bugs). Don't even get me started on

Rob Mensching

2004-05-18 06:44:11 UTC

Permalink

I'm currently working on a new multi-purpose tool much like Jason Swager
did, that is intended to replace the FileGroup element. The intention would
be to run this tool once, then maintain the generated source file(s) after
that so nothing violates the Component Rules. Right now, FileGroup makes it
too easy to use the WiX toolset to hose your customers by messing up your
product's patching/upgrade story.

More information coming soon.

_____

From: Riko Eksteen [mailto:***@korbitec.com]
Sent: Wednesday, May 05, 2004 2:15 AM
To: ***@users.sourceforge.net; Anand Murugesan;
wix-***@lists.sourceforge.net
Subject: RE: [WiX-users] Including all files under a directory

I finally understand why the FileGroup element is so dangerous, and I won't
be using it again (thanks Rob).

I had a look at the component rules in the SDK again, and realised that the
requirements there doesn't fit with FileGroup. Specifically, one should
never add or remove resources from a component without changing the
component code, otherwise those resources might not be
removed/repaired/upgraded etc. Think this is pretty self-evident. If that is
the case, "The <FileGroup/> element is a very dangerous thing to use"
because if files in a folder are included this way, there is no way to know
whether you actually add new resources to an already existing component.

That sent me an a mission to find out how InstallShield's dynamic file
linking works, because it would be subject to the same flaw in logic, so to
speak. InstallShield's dynamic linking includes both subfolders and files,
and what it actually does behind your back is to create new components per
subfolder, include all the files, and set the first as the KeyPath. It also
generates new component codes at build time, so that the above requirement
is met. So this would work, theoretically (we certainly haven't had

problems with it), but it does make it hard to keep track of what files
exactly are included in your components, and might lead to some problems
when doing upgrades.

Anyway, this brings me back to the right way to add files in WiX - manually.
This is fine and dandy, except that I've spent just about a whole day adding
every single xml file in the specific product (there 696 of these files and
212 related folders) and I'm still going. This is a bit of a problem: apart
from the fact that the text-based entry method is error prone, it will be a
hell of an ask to track changes and add them correctly. It is here that
InstallShield has a significant advantage.

I spoke to some of our developers yesterday and they are not very keen to
use something like this - they want an easier way to include files etc. So
now I feel like I'm back to square one - I don't want to use a product like
InstallShield, because 1) it's expensive to distribute all round 2) it does
stuff behind your back 3) it doesn't create the cleanest MSIs (unnecessary
tables etc.). I would like something that would allow the developers to
author and maintain their own MSIs, but Visual Studio Installer is too
high-level (hides everything away) and it looks like WiX will be difficult
to use for large projects, despite it's many advantages.

Any thoughts?

-----Original Message-----
From: Rob Mensching [mailto:***@users.sourceforge.net]
Sent: 04 May 2004 02:12
To: 'Anand Murugesan'; wix-***@lists.sourceforge.net
Subject: RE: [WiX-users] Including all files under a directory

The <FileGroup/> element is a very dangerous thing to use and I always
discourage its use. Autogenerating Components (which would be necessary to
add Files from subdirectories) isn't just dangerous, it is down right scary.
You have to understand the Component Rules
(http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx) and then you'll
see why autogenerating Components for each of your Directories is a really
scary thing to do.

The WiX toolset does not autogenerate Components. Full stop.

_____

From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Anand Murugesan
Sent: Monday, May 03, 2004 4:43 PM
To: wix-***@lists.sourceforge.net
Subject: [WiX-users] Including all files under a directory

Hi All,
I am trying to add all the files (including the subdirectories), under
C:\software\package1 into my MSI.
I am using the following MSI segment. But, it includes only the top level
files in the package1 directory. How do I make it to drill down to all
subdirectories ?
<FileGroup Prefix='bla' DiskId='1' src='C:\software\package1' />

Is this the right approach, or should I consider creating a separate
archieve or cab file and reference it in my wsx file. If thats the better
solution, how do I do that for the above mentioned scenario ?

Thanks,
Anand.

Jason Swager

2004-05-18 15:02:30 UTC

Permalink

Rob,

I learned my lessons in MSI component rules the hard way a long time
ago. The company I work for uses WISE - not a bad tool, but it goes
overboard trying to hide the MSI complexities from you. One of the
features is a "wildcard file add" which is almost exactly like
<FileGroup/>. At first, I thought it was a pretty cool way to add the
some 64,000 or so odd files into our install. And it worked OK for the
first install. But then we started putting conditions on some of the
files, tried to upgrade and patch others, only install some files, etc -
and the install started blowing up pretty badly. After ripping apart the
Wise-generated-MSI we started discovering what Wise was doing and the
reprecussions. Essentially, we broke just about every component rule
there was. We had to rebuild the installation from scratch, this time,
adding each and every file very carefully. We still had to do a large
amount of manual component work; Wise kept getting in the way and trying
to build components based on its own internal rules.

So far, the tool is working OK. Sorry, I can't release the code; I made
the mistake of building it during work hours which automatically placed
it under our propietary code rules. Oops.

The first version would just recurse directories building out
<Directory>, <Component> and <File> nodes for each file/directory
encountered. Each <File> was given its own unique Id based on the path,
unique GUID, long/short name handling was performed, each file was its
own key path. Developers here didn't like it; took too long to delete
all the extraneous <Component> entries. Second version would create a
new <Component> (and GUID) only when special extension types were
encountered, such as EXE, DLL, OCX, CHM, etc (made it expandable via the
command line). Files that didn't have a special extension would
automatically be grouped into the last created component. Developers
still didn't like that because the tool was grouping all files based on
FindFirst, FindNext ordering, which meant that some of the component/file
sets still had to be adjusted manually.

In frustration, withdrew the tool and told the developers to start typing
XML, they had about 63,900 files to go, don't make any typos, all file
Ids better be unique, and no coping GUIDs. They chose to use the tool,
this time no complaints.

So yes, the tool is working OK. I would feel better if the tool were
actually part of the WiX toolset, just in case something changes in the
WiX schema or something. I look forward to seeing the tool that you're
writing for WiX.

Jason Swager

-----Original Message-----
From: "Rob Mensching" <***@users.sourceforge.net>
To: "***@alohaoi.com" <***@alohaoi.com>, "wix-
***@lists.sourceforge.net" <wix-***@lists.sourceforge.net>
Date: Tue, 18 May 2004 06:16:57 -0700
Subject: RE: [WiX-users] Including all files under a directory

Post by Rob Mensching
Jason, I'm thinking about removing <FileGroup/> and adding a tool that
does
this sort of thing to the WiX toolset. I'm curious how this process
has
worked out for you?
What you are doing here is the safest process that I've seen
(considering
how restrictive the Component Rules are).
_____
Swager
Sent: Wednesday, May 05, 2004 6:29 AM
Subject: RE: [WiX-users] Including all files under a directory
I've encountered the same issues; too many files to type into WIX. In
our
case, we've currently got about 66,000 files per install. We don't put
every file in its own component, but it's still a massive amount of
typing.
Prior to WIX, we were using WISE, which appears to have the same
problems as
Install Shield and does things behind your back.
However, to at least make the initial work easier, we wrote a quick
little
program that simply walks through specific directory and/or
subdirectories,
building a partial WIX fragment as it goes. For every directory/file
found,
it would expand the WIX fragment with the appropriate XML. Each file
was
assigned a new component ID. After each fragment was built, a
developer
would go and decide which files could be grouped into a single
component,
and which ones would need to be on their own. That makes it MUCH
easier to
maintain.
Jason
-----Original Message-----
Sent: Wednesday, May 05, 2004 5:39 AM
Subject: Re: [WiX-users] Including all files under a directory
I spoke to some of our developers yesterday and they are not very keen
to
use something like this - they want an easier way to include files etc.
So
now I feel like I'm back to square one - I don't want to use a product
like
InstallShield, because 1) it's expensive to distribute all round 2) it
does
stuff behind your back 3) it doesn't create the cleanest MSIs
(unnecessary
tables etc.). I would like something that would allow the developers to
author and maintain their own MSIs, but Visual Studio Installer is too
high-level (hides everything away) and it looks like WiX will be
difficult
to use for large projects, despite it's many advantages.
Any thoughts?
I agree. I've got a lot of experience with Installshield and (imho)
it's
awful. Does god knows what in the background, which slows things down
and
adds complexity (more complexity == more bugs). Don't even get me
started on
"Installscript" :-)

Rob Mensching

2004-05-18 06:41:25 UTC

Permalink

1. If you don't specify a KeyPath the first resource in the Component that
can be a KeyPath will be. Since your File is first in the Component it will
be the KeyPath.

2. This is a really expensive way to author your setup since the Windows
Installer has overhead for each Component in the install. However, this is
also the safest way to make your package considering the Component Rules.

3. You definitely do not want to change the GUID of the Component on each
update. The Component GUID only changes when the Component is no longer
100% backwards compatible or has resources added to it. However, when you
change the GUID you must ensure that your new Component has no overlap (i.e.
does not install any of the resources) with other Components. This is the
core of the Component Rules.

_____

From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Jamie Cansdale
Sent: Wednesday, May 05, 2004 7:15 AM
To: 'Riko Eksteen'; ***@users.sourceforge.net; 'Anand Murugesan';
wix-***@lists.sourceforge.net
Subject: RE: [WiX-users] Including all files under a directory

I've been working on a command line tool that updates the File, Directory
and Component elements in a WXS file based on the projects in a Visual
Studio solution. At the moment it copies all files with a 'Build Action' of
'Content' and all project outputs for a specified solution configuration.
Each file gets its own File and Component element allowing with any
Directory elements as needed. The Component.Guid, Id and File.Id are based
on a hash of the relative path (I know the Component.Guid should be combined
with something else!). It is very much a work in progress. Let me know
what I'm missing or doing wrong! Here is an example of what it outputs at
the moment.

(Here's a build of NUnitAddIn created using it)

http://weblogs.asp.net/nunitaddin/archive/2004/05/01/124453.aspx

Because it updates the WXS file rather than recreating I can add things like
custom actions. Because the File.Id and ComponentId are a hash of the
project items relative path they will remain consistent between updates. It
is everything under ModuleDir that has been generated.

Should File.KeyPath be set to 'yes'?

Should Component.Id be randomized on each update?

<?xml version="1.0" encoding="utf-8"?>

<Wix xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://schemas.microsoft.com/wix/2003/01/wi">

<Module Id="NUnitAddin.sln" Guid="5FA9934D3F3341BBB28C6026583BC45C"
Language="1033" Version="1.0.0.0">

<Package Id="3807327122724060A7423BF1DE5C7FA5" Description="From
solution 'NUnitAddin.sln'" Comments="Auto generated with Sln2Wix"
Manufacturer="Mutant Design" InstallerVersion="200" Compressed="yes" />

<InstallExecuteSequence>



<Custom Action="Install"
After="InstallFinalize">$C_a14fc90fa19a9a5acdbea8f24e4cb8ef>2</Custom>



<Custom Action="Uninstall"
Before="MsiUnpublishAssemblies">$C_a14fc90fa19a9a5acdbea8f24e4cb8ef=2</Custo
m>

</InstallExecuteSequence>

<CustomAction Id="Install" FileKey="F_a14fc90fa19a9a5acdbea8f24e4cb8ef"
ExeCommand="/install" Execute="immediate" />

<CustomAction Id="Uninstall"
FileKey="F_a14fc90fa19a9a5acdbea8f24e4cb8ef" ExeCommand="/uninstall"
Execute="immediate" />

<Directory Id="TARGETDIR" Name="SourceDir">

<Directory Id="ModuleDir" Name=".">

<Directory Id="D_605c646ba3f747c9b24bb1a277193aa2" Name="icons"
LongName="icons">

<Component Id="C_61fbcd6caea5c8e88f720a55d9df8e02"
Guid="61fbcd6c-aea5-c8e8-8f72-0a55d9df8e02">

<File Id="F_61fbcd6caea5c8e88f720a55d9df8e02" Name="Debug.ico"
LongName="Debug.ico" src="NUnitAddin\icons\Debug.ico" />

</Component>

<Component Id="C_a8db7eb234f62c179194d360ada47525"
Guid="a8db7eb2-34f6-2c17-9194-d360ada47525">

<File Id="F_a8db7eb234f62c179194d360ada47525" Name="NUnit.ico"
LongName="NUnit.ico" src="NUnitAddin\icons\NUnit.ico" />

</Component>

<Component Id="C_be78b109c9f515e5a360bcd79a4822ea"
Guid="be78b109-c9f5-15e5-a360-bcd79a4822ea">

<File Id="F_be78b109c9f515e5a360bcd79a4822ea" Name="Runtime.ico"
LongName="Runtime.ico" src="NUnitAddin\icons\Runtime.ico" />

</Component>

<Component Id="C_0fa6f464d88f67139a06edd87e5c5c0e"
Guid="0fa6f464-d88f-6713-9a06-edd87e5c5c0e">

<File Id="F_0fa6f464d88f67139a06edd87e5c5c0e"
Name="VISUAL~1.ICO" LongName="VisualStudio.ico"
src="NUnitAddin\icons\VisualStudio.ico" />

</Component>

</Directory>

<Directory Id="D_577b9fd8db914fc3b27da51091ab143b" Name="runtimes"
LongName="runtimes">

<Component Id="C_d02d696b9530b17f7c0fb25fbc756d19"
Guid="d02d696b-9530-b17f-7c0f-b25fbc756d19">

<File Id="F_d02d696b9530b17f7c0fb25fbc756d19"
Name="CDP_AP~1.CON" LongName="CDP_Apartment.config"
src="NUnitAddin\runtimes\CDP_Apartment.config" />

</Component>

<Component Id="C_992d17046bcf574f67a260aba454b637"
Guid="992d1704-6bcf-574f-67a2-60aba454b637">

<File Id="F_992d17046bcf574f67a260aba454b637"
Name="CDP_MA~1.CON" LongName="CDP_Marshaling.config"
src="NUnitAddin\runtimes\CDP_Marshaling.config" />

</Component>

<Component Id="C_3626c8bac9756919f631b830d6213c85"
Guid="3626c8ba-c975-6919-f631-b830d6213c85">

<File Id="F_3626c8bac9756919f631b830d6213c85" Name="MONO~1.CON"
LongName="mono.config" src="NUnitAddin\runtimes\mono.config" />

</Component>

<Component Id="C_4b2fb538595fafa3207fb503cbcc730c"
Guid="4b2fb538-595f-afa3-207f-b503cbcc730c">

<File Id="F_4b2fb538595fafa3207fb503cbcc730c" Name="NET10~1.CON"
LongName="net10.config" src="NUnitAddin\runtimes\net10.config" />

</Component>

<Component Id="C_14eb7860f8128506c36a706e0e14a193"
Guid="14eb7860-f812-8506-c36a-706e0e14a193">

<File Id="F_14eb7860f8128506c36a706e0e14a193" Name="NET11~1.CON"
LongName="net11.config" src="NUnitAddin\runtimes\net11.config" />

</Component>

<Component Id="C_076902cce67640035c94c11cde5c617c"
Guid="076902cc-e676-4003-5c94-c11cde5c617c">

<File Id="F_076902cce67640035c94c11cde5c617c" Name="NET12~1.CON"
LongName="net12.config" src="NUnitAddin\runtimes\net12.config" />

</Component>

<Component Id="C_97fbf17a2993af20f32712832b5fbcc7"
Guid="97fbf17a-2993-af20-f327-12832b5fbcc7">

<File Id="F_97fbf17a2993af20f32712832b5fbcc7" Name="NET20~1.CON"
LongName="net20.config" src="NUnitAddin\runtimes\net20.config" />

</Component>

</Directory>

<Directory Id="D_e8a17bec33054952bb6f31dbdb2e7a81" Name="lib"
LongName="lib">

<Component Id="C_d68012501a3e4796a09f43b0208902b1"
Guid="d6801250-1a3e-4796-a09f-43b0208902b1">

<File Id="F_d68012501a3e4796a09f43b0208902b1"
Name="MUTANT~3.DLL" LongName="MutantDesign.ManagedAddIns.dll"
src="..\ManagedAddIns\Tests\bin\MutantDesign.ManagedAddIns.dll" />

</Component>

<Component Id="C_79ba08747349da554584d763e9c3b536"
Guid="79ba0874-7349-da55-4584-d763e9c3b536">

<File Id="F_79ba08747349da554584d763e9c3b536"
Name="MUTANT~3.DLL" LongName="MutantDesign.ManagedAddIns.Services.dll"
src="..\ManagedAddIns\Tests\bin\MutantDesign.ManagedAddIns.Services.dll" />

</Component>

</Directory>

<Component Id="C_0d57b7d4022f1f0ee5cf9f3dc3e40020"
Guid="0d57b7d4-022f-1f0e-e5cf-9f3dc3e40020">

<File Id="F_0d57b7d4022f1f0ee5cf9f3dc3e40020" Name="MUTANT~1.DLL"
LongName="MutantDesign.ManagedAddIns.Services.dll"
src="NUnitAddin\..\..\ManagedAddIns\Tests\bin\MutantDesign.ManagedAddIns.Ser
vices.dll" />

</Component>

<Component Id="C_fdfe27ba7225eefb183c7fa00e00c9b4"
Guid="fdfe27ba-7225-eefb-183c-7fa00e00c9b4">

<File Id="F_fdfe27ba7225eefb183c7fa00e00c9b4" Name="Notes.htm"
LongName="Notes.htm" src="NUnitAddin\Notes.htm" />

</Component>

<Component Id="C_43a46a698b77ff2ea398a9c3ce6f717f"
Guid="43a46a69-8b77-ff2e-a398-a9c3ce6f717f">

<File Id="F_43a46a698b77ff2ea398a9c3ce6f717f" Name="NUNITA~1.CON"
LongName="nunitaddin.config" src="NUnitAddin\nunitaddin.config" />

</Component>

<Component Id="C_a14fc90fa19a9a5acdbea8f24e4cb8ef"
Guid="a14fc90f-a19a-9a5a-cdbe-a8f24e4cb8ef">

<File Id="F_a14fc90fa19a9a5acdbea8f24e4cb8ef" Name="NUNITA~1.EXE"
LongName="NUnitAddin.exe" src="NUnitAddin\bin\Debug\NUnitAddin.exe" />

</Component>

<Component Id="C_d1f9216d472c9165285a3517afc5c8c6"
Guid="d1f9216d-472c-9165-285a-3517afc5c8c6">

<File Id="F_d1f9216d472c9165285a3517afc5c8c6" Name="NUNITA~2.CON"
LongName="NUnitAddin.exe.config"
src="NUnitAddin\bin\Debug\NUnitAddin.exe.config" />

</Component>

<Component Id="C_4c92e542556b64cb5e7ced616636c9bd"
Guid="4c92e542-556b-64cb-5e7c-ed616636c9bd">

<File Id="F_4c92e542556b64cb5e7ced616636c9bd" Name="MUTANT~1.DLL"
LongName="MutantDesign.dll" src="MutantDesign\bin\Debug\MutantDesign.dll" />

</Component>

<Component Id="C_bbbb3733bacceab10740626158732f7a"
Guid="bbbb3733-bacc-eab1-0740-626158732f7a">

<File Id="F_bbbb3733bacceab10740626158732f7a" Name="MUTANT~1.DLL"
LongName="MutantDesign.EnvDte.dll"
src="MutantDesign.EnvDte\bin\Debug\MutantDesign.EnvDte.dll" />

</Component>

<Component Id="C_c26efcbb5aa7ad9545db861cc3e188fd"
Guid="c26efcbb-5aa7-ad95-45db-861cc3e188fd">

<File Id="F_c26efcbb5aa7ad9545db861cc3e188fd" Name="NUNITA~1.DLL"
LongName="NUnitAddin.TestRunner.dll"
src="NUnitAddin.TestRunner\bin\Debug\NUnitAddin.TestRunner.dll" />

</Component>

<Component Id="C_cea1597c41a7fc9d2a6ad6174ed3829f"
Guid="cea1597c-41a7-fc9d-2a6a-d6174ed3829f">

<File Id="F_cea1597c41a7fc9d2a6ad6174ed3829f" Name="NUNITA~1.DLL"
LongName="NUnitAddin.TestRunner.Framework.dll"
src="NUnitAddin.TestRunner.Framework\bin\Debug\NUnitAddin.TestRunner.Framewo
rk.dll" />

</Component>

<Component Id="C_dd1cc65557fa1b0aad383b8241a69d08"
Guid="dd1cc655-57fa-1b0a-ad38-3b8241a69d08">

<File Id="F_dd1cc65557fa1b0aad383b8241a69d08" Name="NUNITA~1.DLL"
LongName="NUnitAddin.TestRunner.Runtimes.dll"
src="NUnitAddin.TestRunner.Runtimes\bin\Debug\NUnitAddin.TestRunner.Runtimes
.dll" />

</Component>

<Component Id="C_336119253d86417257327f18a666614f"
Guid="33611925-3d86-4172-5732-7f18a666614f">

<File Id="F_336119253d86417257327f18a666614f" Name="NUNITA~1.DLL"
LongName="NUnitAddin.AdHoc.dll"
src="NUnitAddin.AdHoc\bin\Debug\NUnitAddin.AdHoc.dll" />

</Component>

<Component Id="C_c4fbba73ae9ea15c7c8da7260d564159"
Guid="c4fbba73-ae9e-a15c-7c8d-a7260d564159">

<File Id="F_c4fbba73ae9ea15c7c8da7260d564159" Name="NUNITC~1.DLL"
LongName="nunit.core.dll" src="NUnitAddin.NUnit\..\bin\NUnit\nunit.core.dll"
/>

</Component>

<Component Id="C_7d8d4deb750f1cdb13877abcd095bcd7"
Guid="7d8d4deb-750f-1cdb-1387-7abcd095bcd7">

<File Id="F_7d8d4deb750f1cdb13877abcd095bcd7" Name="NUNITF~1.DLL"
LongName="nunit.framework.dll"
src="NUnitAddin.NUnit\..\bin\NUnit\nunit.framework.dll" />

</Component>

<Component Id="C_70d92e0fa3048fcbc862c509bf833e4c"
Guid="70d92e0f-a304-8fcb-c862-c509bf833e4c">

<File Id="F_70d92e0fa3048fcbc862c509bf833e4c" Name="NUNITU~1.DLL"
LongName="nunit.uikit.dll"
src="NUnitAddin.NUnit\..\bin\NUnit\nunit.uikit.dll" />

</Component>

<Component Id="C_2676255db2265d5b5701d20b35c1da89"
Guid="2676255d-b226-5d5b-5701-d20b35c1da89">

<File Id="F_2676255db2265d5b5701d20b35c1da89" Name="NUNITU~1.DLL"
LongName="nunit.util.dll" src="NUnitAddin.NUnit\..\bin\NUnit\nunit.util.dll"
/>

</Component>

<Component Id="C_b88e98ae33aebcedf8500d6283320836"
Guid="b88e98ae-33ae-bced-f850-0d6283320836">

<File Id="F_b88e98ae33aebcedf8500d6283320836" Name="NUNIT-~1.EXE"
LongName="nunit-console.exe"
src="NUnitAddin.NUnit\..\bin\NUnit\nunit-console.exe" />

</Component>

<Component Id="C_6b3a3e57c4a46a6851e05d8ed4020963"
Guid="6b3a3e57-c4a4-6a68-51e0-5d8ed4020963">

<File Id="F_6b3a3e57c4a46a6851e05d8ed4020963" Name="NUNIT-~1.EXE"
LongName="nunit-gui.exe" src="NUnitAddin.NUnit\..\bin\NUnit\nunit-gui.exe"
/>

</Component>

<Component Id="C_a05778b889dc8f8bc2db9a3ec575f23a"
Guid="a05778b8-89dc-8f8b-c2db-9a3ec575f23a">

<File Id="F_a05778b889dc8f8bc2db9a3ec575f23a" Name="NUNITA~1.DLL"
LongName="NUnitAddin.NUnit.dll"
src="NUnitAddin.NUnit\bin\Debug\NUnitAddin.NUnit.dll" />

</Component>

<Component Id="C_7f34010c9d32ab9b9b72a761dbc8e483"
Guid="7f34010c-9d32-ab9b-9b72-a761dbc8e483">

<File Id="F_7f34010c9d32ab9b9b72a761dbc8e483" Name="NUNITA~1.DLL"
LongName="NUnitAddin.TestRunner.Server.dll"
src="NUnitAddin.TestRunner.Server\bin\Debug\NUnitAddin.TestRunner.Server.dll
" />

</Component>

<Component Id="C_cf2d9a23bab91fa0d04faebd7b838cb0"
Guid="cf2d9a23-bab9-1fa0-d04f-aebd7b838cb0">

<File Id="F_cf2d9a23bab91fa0d04faebd7b838cb0" Name="NUNITA~1.DLL"
LongName="NUnitAddin.Services.dll"
src="NUnitAddin.Services\bin\Debug\NUnitAddin.Services.dll" />

</Component>

<Component Id="C_88e0487a3873e87e79b151e4f004a4b6"
Guid="88e0487a-3873-e87e-79b1-51e4f004a4b6">

<File Id="F_88e0487a3873e87e79b151e4f004a4b6" Name="App.ico"
LongName="App.ico" src="WebServices\App.ico" />

</Component>

<Component Id="C_0226e97e099f56c9459e8cc37f0f81fc"
Guid="0226e97e-099f-56c9-459e-8cc37f0f81fc">

<File Id="F_0226e97e099f56c9459e8cc37f0f81fc" Name="TESTRU~1.ASM"
LongName="TestRunner.asmx" src="WebServices\TestRunner.asmx" />

</Component>

<Component Id="C_abaed4346402a89d24af5227fce1a2a7"
Guid="abaed434-6402-a89d-24af-5227fce1a2a7">

<File Id="F_abaed4346402a89d24af5227fce1a2a7" Name="WEB~1.CON"
LongName="Web.config" src="WebServices\Web.config" />

</Component>

<Component Id="C_efd8794321b374a62aa46415f0d4d49f"
Guid="efd87943-21b3-74a6-2aa4-6415f0d4d49f">

<File Id="F_efd8794321b374a62aa46415f0d4d49f" Name="NUNITA~1.DLL"
LongName="NUnitAddIn.WebServices.dll"
src="WebServices\bin\NUnitAddIn.WebServices.dll" />

</Component>

<Component Id="C_fd9a11e3d4055031bae078fd126e12a9"
Guid="fd9a11e3-d405-5031-bae0-78fd126e12a9">

<File Id="F_fd9a11e3d4055031bae078fd126e12a9" Name="NUNITA~1.DLL"
LongName="NUnitAddin.Tests.dll" src="bin\Debug\NUnitAddin.Tests.dll" />

</Component>

<Component Id="C_cdb5b4cd6f1c302d0c477730dce4198c"
Guid="cdb5b4cd-6f1c-302d-0c47-7730dce4198c">

<File Id="F_cdb5b4cd6f1c302d0c477730dce4198c" Name="NUNITA~1.DLL"
LongName="NUnitAddin.Tools.dll"
src="NUnitAddin.Tools\bin\Debug\NUnitAddin.Tools.dll" />

</Component>

<Component Id="C_c0039f0449819281a564efaf1b127a46"
Guid="c0039f04-4981-9281-a564-efaf1b127a46">

<File Id="F_c0039f0449819281a564efaf1b127a46" Name="PROCES~1.EXE"
LongName="ProcessInvocation.exe"
src="ProcessInvocation\bin\ProcessInvocation.exe" />

</Component>

</Directory>

</Directory>

</Module>

</Wix>

_____

From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Riko Eksteen
Sent: 05 May 2004 10:15
To: ***@users.sourceforge.net; Anand Murugesan;
wix-***@lists.sourceforge.net
Subject: RE: [WiX-users] Including all files under a directory

I finally understand why the FileGroup element is so dangerous, and I won't
be using it again (thanks Rob).

I had a look at the component rules in the SDK again, and realised that the
requirements there doesn't fit with FileGroup. Specifically, one should
never add or remove resources from a component without changing the
component code, otherwise those resources might not be
removed/repaired/upgraded etc. Think this is pretty self-evident. If that is
the case, "The <FileGroup/> element is a very dangerous thing to use"
because if files in a folder are included this way, there is no way to know
whether you actually add new resources to an already existing component.

That sent me an a mission to find out how InstallShield's dynamic file
linking works, because it would be subject to the same flaw in logic, so to
speak. InstallShield's dynamic linking includes both subfolders and files,
and what it actually does behind your back is to create new components per
subfolder, include all the files, and set the first as the KeyPath. It also
generates new component codes at build time, so that the above requirement
is met. So this would work, theoretically (we certainly haven't had

problems with it), but it does make it hard to keep track of what files
exactly are included in your components, and might lead to some problems
when doing upgrades.

Anyway, this brings me back to the right way to add files in WiX - manually.
This is fine and dandy, except that I've spent just about a whole day adding
every single xml file in the specific product (there 696 of these files and
212 related folders) and I'm still going. This is a bit of a problem: apart
from the fact that the text-based entry method is error prone, it will be a
hell of an ask to track changes and add them correctly. It is here that
InstallShield has a significant advantage.

I spoke to some of our developers yesterday and they are not very keen to
use something like this - they want an easier way to include files etc. So
now I feel like I'm back to square one - I don't want to use a product like
InstallShield, because 1) it's expensive to distribute all round 2) it does
stuff behind your back 3) it doesn't create the cleanest MSIs (unnecessary
tables etc.). I would like something that would allow the developers to
author and maintain their own MSIs, but Visual Studio Installer is too
high-level (hides everything away) and it looks like WiX will be difficult
to use for large projects, despite it's many advantages.

Any thoughts?

-----Original Message-----
From: Rob Mensching [mailto:***@users.sourceforge.net]
Sent: 04 May 2004 02:12
To: 'Anand Murugesan'; wix-***@lists.sourceforge.net
Subject: RE: [WiX-users] Including all files under a directory

The <FileGroup/> element is a very dangerous thing to use and I always
discourage its use. Autogenerating Components (which would be necessary to
add Files from subdirectories) isn't just dangerous, it is down right scary.
You have to understand the Component Rules
(http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx) and then you'll
see why autogenerating Components for each of your Directories is a really
scary thing to do.

The WiX toolset does not autogenerate Components. Full stop.

_____

From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Anand Murugesan
Sent: Monday, May 03, 2004 4:43 PM
To: wix-***@lists.sourceforge.net
Subject: [WiX-users] Including all files under a directory

Hi All,
I am trying to add all the files (including the subdirectories), under
C:\software\package1 into my MSI.
I am using the following MSI segment. But, it includes only the top level
files in the package1 directory. How do I make it to drill down to all
subdirectories ?
<FileGroup Prefix='bla' DiskId='1' src='C:\software\package1' />

Is this the right approach, or should I consider creating a separate
archieve or cab file and reference it in my wsx file. If thats the better
solution, how do I do that for the above mentioned scenario ?

Thanks,
Anand.

Rob Mensching

2004-05-25 04:14:37 UTC

Permalink

So NSIS doesn't have any compensating transaction concepts?

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Steve
Christensen
Sent: Tuesday, May 18, 2004 4:48 PM
To: wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Including all files under a directory

Hi Rob,

I'm not sure what you're asking here. If it is in regards to my question
about using the md5 hashes to generate GUIDs, that was more dealing with
my having the wrong idea about component GUIDs.

NSIS does not use Windows Installer, and is strictly packaging /
scripting tool. As such, it does a decent job. My primary reasons for
picking it over Wise (either in its newer windows installer or older
versions) was that it allowed us to check-in a text file that everyone
could read and verify without a special editor. There are also no
licensing hurdles that stopped the developers from using it to package
up their own builds.

WiX also fits on both counts, which is why we're looking at it.

-Steve

Rob Mensching

2004-05-25 04:17:09 UTC

Permalink

Yeah, I was hesitant about allowing the Id to be missing and autogen'ing the
GUID. -1 and autogen seem a bit weird. What about a GUID with all X's?
For example:

Id='XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'

That should be pretty clear what gets replaced? I guess I'm looking for
ideas. Any other suggestions out there?

-----Original Message-----
From: Orion Edwards [mailto:***@coke.net.nz]
Sent: Tuesday, May 18, 2004 3:17 PM
Cc: Steve Christensen;
Subject: RE: [WiX-users] Including all files under a directory

Post by Rob Mensching
I don't want to add a way to autogenerate GUIDs anywhere because I am
attributes. Doing so would be even worse than abusing the dreaded

FileGroup

Post by Rob Mensching
element.

Being aware of the component rules, I agree. - I'm not auto generating
anything
except for the Product and Package Codes. Component GUIDs are all authored
into
the script (that visual studio generate GUID macro is rather handy :-) )

Post by Rob Mensching
Instead, Orion, I think we should target the scenario you're trying to hit
narrowly. So, I'm thinking maybe the right fix is to allow the

autogenerated

Post by Rob Mensching
for you. I'm still working through all the patching repercussions of this
type of behavior, but it seems like a decent tradeoff.

Fine by me, however I think that keeping the Id attribute mandatory in the
element and giving it some special value like -1 or "autogen" or something
to
cause auto-generation may be a better idea, as an auto generated product
code
is probably not the norm. Simply leaving things out to autogen them is a
great
way to cause confusion and problems down the track if you ever have more
than
one developer working on your installer(s).

Rob Mensching

2004-05-28 06:56:12 UTC

Permalink

What do you mean, "changing the keypath with ever build"? Are you changing
the contents of your Components?

-----Original Message-----
From: Steve Christensen [mailto:***@xmission.com]
Sent: Tuesday, May 25, 2004 10:40 AM
To: Rob Mensching
Cc: Terry Denham; wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Including all files under a directory

OK, I think I understand a bit better now about when the component GUIDs
need to change.

However, I do still have cases where I'm going to need to change every
component GUID with every automated build (the keypath is changing with
every build).

The path to the software installation is:
"<product name> + <version number> + <build number>"
(myproduct_v1.0.0_d845).

The build number changes with every build. Yes, that means the customer
can have multiple copies of the application on their system. That
allows them to install a new release during off-hours for acceptance
testing, but still maintain known-good build for training during the
day.

So, I'd definitely like an easy way to tell candle to generate a new
GUID for a Component, not just the Product/Package IDs. But I understand
if it is out-of-the-norm enough (or dangerous enough) that I'll need to
patch candle myself or have some other pre-processing mechanism to
generate the GUIDs.

-Steve

Post by Terry Denham
Why do you need to create a new GUID for every build? This seems to be a
waste. A guid is only used to identify the component within the package

but

Post by Terry Denham
if the file doensn't change location then I don't see any reason to

regen

Post by Rob Mensching

Post by Terry Denham
the guid, or am I missing something?

If each automated build produces a new MSI file with non-identical
contents, doesn't that mean each MSI needs a unique PackageCode GUID?
When we're talking 4-5 MSIs as the products of every automated build, it
seems unrealistic to expect someone to update those GUIDs by hand.
Component GUIDs for data files packaged up with the application wouldn't
necessarily have to change, but shouldn't the components holding the
compiled applications/libraries change GUIDs more often, if not every
build?
Maybe I'm misreading the component documentation... I'm still very much
in the 'install scripting' mindset rather than the Windows Installer
mindset... If the system will only install a component if it hasn't
already been installed, doesn't that mean the component GUID needs to be
updated to ensure that the software produced by a particular build is
installed as one coherent piece?
-Steve
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users

Steve Christensen

2004-05-28 17:46:15 UTC

Permalink

Sorry, I should have said target location rather than keypath.

For example, if the customer has the 1.1, 1.2 releases and a 1.3 testing
candidate on their system, they'd all get installed side-by-side:

c:\program files\<company name>\<prodname>_1.1_r60
\bin\prodname.exe
\bin\prodname.dll
c:\program files\<company name>\<prodname>_1.2_r85
\bin\prodname.exe
\bin\prodname.dll
c:\program files\<company name>\<prodname>_1.3_d60
\bin\prodname.exe
\bin\prodname.dll

To get the three different versions of prodname.exe onto the system,
they'd need different component GUIDs in their respective version's MSI
file, right?

-Steve

Post by Rob Mensching
What do you mean, "changing the keypath with ever build"? Are you changing
the contents of your Components?
-----Original Message-----
Sent: Tuesday, May 25, 2004 10:40 AM
To: Rob Mensching
Subject: Re: [WiX-users] Including all files under a directory
OK, I think I understand a bit better now about when the component GUIDs
need to change.
However, I do still have cases where I'm going to need to change every
component GUID with every automated build (the keypath is changing with
every build).
"<product name> + <version number> + <build number>"
(myproduct_v1.0.0_d845).
The build number changes with every build. Yes, that means the customer
can have multiple copies of the application on their system. That
allows them to install a new release during off-hours for acceptance
testing, but still maintain known-good build for training during the
day.
So, I'd definitely like an easy way to tell candle to generate a new
GUID for a Component, not just the Product/Package IDs. But I understand
if it is out-of-the-norm enough (or dangerous enough) that I'll need to
patch candle myself or have some other pre-processing mechanism to
generate the GUIDs.
-Steve

Post by Terry Denham
Why do you need to create a new GUID for every build? This seems to be a
waste. A guid is only used to identify the component within the package

but

Post by Terry Denham
if the file doensn't change location then I don't see any reason to

regen

Post by Rob Mensching

Post by Terry Denham
the guid, or am I missing something?

If each automated build produces a new MSI file with non-identical
contents, doesn't that mean each MSI needs a unique PackageCode GUID?
When we're talking 4-5 MSIs as the products of every automated build, it
seems unrealistic to expect someone to update those GUIDs by hand.
Component GUIDs for data files packaged up with the application wouldn't
necessarily have to change, but shouldn't the components holding the
compiled applications/libraries change GUIDs more often, if not every
build?
Maybe I'm misreading the component documentation... I'm still very much
in the 'install scripting' mindset rather than the Windows Installer
mindset... If the system will only install a component if it hasn't
already been installed, doesn't that mean the component GUID needs to be
updated to ensure that the software produced by a particular build is
installed as one coherent piece?
-Steve
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users

Rob Mensching

2004-05-28 17:55:10 UTC

Permalink

No, not necessarily. Okay. It is clear I need to do another pass on the
Component Rules. Let me see if I can get to a blog entry about this by the
end of next weekend.

To answer your near term question, you really only need to fix the Component
GUIDs when you ship. During development you can break the Component Rules
(you'll have to suffer the upgrade issues, but that's part of development).
In fact, to use most of the advanced features of the Windows Installer
(which I've only ever seen Office really take advantage of) you need to keep
your Component GUIDs static during development (or you end up changing a lot
of code).

It is only when you ship a version of your MSI that you intend to support
for extended periods of time that you need to fix the GUIDs and ensure there
is no overlap.

Like I said, I think I see where a bit more of the confusion lies, and I'll
try to clear it up in a writing so that many people can take advantage of
it.

Thanks.

-----Original Message-----
From: Steve Christensen [mailto:***@xmission.com]
Sent: Friday, May 28, 2004 10:46
To: Rob Mensching
Cc: Terry Denham; wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Including all files under a directory

Sorry, I should have said target location rather than keypath.

For example, if the customer has the 1.1, 1.2 releases and a 1.3 testing
candidate on their system, they'd all get installed side-by-side:

c:\program files\<company name>\<prodname>_1.1_r60
\bin\prodname.exe
\bin\prodname.dll
c:\program files\<company name>\<prodname>_1.2_r85
\bin\prodname.exe
\bin\prodname.dll
c:\program files\<company name>\<prodname>_1.3_d60
\bin\prodname.exe
\bin\prodname.dll

To get the three different versions of prodname.exe onto the system,
they'd need different component GUIDs in their respective version's MSI
file, right?

-Steve

Post by Rob Mensching
What do you mean, "changing the keypath with ever build"? Are you

changing

Post by Rob Mensching
the contents of your Components?
-----Original Message-----
Sent: Tuesday, May 25, 2004 10:40 AM
To: Rob Mensching
Subject: Re: [WiX-users] Including all files under a directory
OK, I think I understand a bit better now about when the component GUIDs
need to change.
However, I do still have cases where I'm going to need to change every
component GUID with every automated build (the keypath is changing with
every build).
"<product name> + <version number> + <build number>"
(myproduct_v1.0.0_d845).
The build number changes with every build. Yes, that means the customer
can have multiple copies of the application on their system. That
allows them to install a new release during off-hours for acceptance
testing, but still maintain known-good build for training during the
day.
So, I'd definitely like an easy way to tell candle to generate a new
GUID for a Component, not just the Product/Package IDs. But I understand
if it is out-of-the-norm enough (or dangerous enough) that I'll need to
patch candle myself or have some other pre-processing mechanism to
generate the GUIDs.
-Steve

Post by Rob Mensching
will be autogenerated every build.
2. DO NOT change the Guids on your Components with every build. Steve,

Post by Rob Mensching

Post by Rob Mensching
highly suggest reading through the Component Rules before going much
http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx that has

links

Post by Rob Mensching

Post by Rob Mensching
to all the available information that I know of right now. I think I'm
going to have to try and write a cleaner version of all this since

people

Post by Rob Mensching

Post by Rob Mensching
seem to be consistently confused.
-----Original Message-----
Christensen
Sent: Thursday, May 06, 2004 3:52 PM
To: Terry Denham
Subject: Re: [WiX-users] Including all files under a directory

Post by Terry Denham
Why do you need to create a new GUID for every build? This seems to be

Post by Rob Mensching

Post by Terry Denham
waste. A guid is only used to identify the component within the

package

Post by Rob Mensching

Post by Rob Mensching
but

Post by Terry Denham
if the file doensn't change location then I don't see any reason to

regen

Post by Rob Mensching

Post by Terry Denham
the guid, or am I missing something?

If each automated build produces a new MSI file with non-identical
contents, doesn't that mean each MSI needs a unique PackageCode GUID?
When we're talking 4-5 MSIs as the products of every automated build, it
seems unrealistic to expect someone to update those GUIDs by hand.
Component GUIDs for data files packaged up with the application wouldn't
necessarily have to change, but shouldn't the components holding the
compiled applications/libraries change GUIDs more often, if not every
build?
Maybe I'm misreading the component documentation... I'm still very much
in the 'install scripting' mindset rather than the Windows Installer
mindset... If the system will only install a component if it hasn't
already been installed, doesn't that mean the component GUID needs to be
updated to ensure that the software produced by a particular build is
installed as one coherent piece?
-Steve
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users