Re: [WiX-users] About DownloadURL

[Benjamin Mayrargue]

2013/6/1 Rob Mensching 

> More specifically, you cannot use RemotePayload element and
> Compressed='yes' on the ExePackage element together. That doesn't make
> sense and the bug here is that the compiler didn't give you an error
> message here saying that. 
>


Exaclty, you have understood !
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Why is install not elevated? Access Denied to Program Files (deferred CA)

[Rob Mensching]

Is it possible the directory has been marked for deletion? That is another
way to get access denied (something else, or something earlier in your MSI)
caused the directory to be deleted but some process has a handle locking
the directory so it isn't gone yet... but the operating system won't let
you access the directory until the handle is closed and the directory is
deleted (then you can create it again).

I've seen this happening quite a bit in installs lately with lots of
different customers.

Just a thought.


On Fri, May 31, 2013 at 3:21 AM, Tom -  wrote:

> Good afternoon,
>
> This is driving me crazy. I can on my Windows 7 run this installation I've
> created and the custom action successfully writes a database backup-file (a
> .bak-file that it has as an embedded resource in its assembly) to the
> Temp-directory provided by Path.GetTempPath(). On my computer, it restores
> this database successfully, creating the MDF/LDF database-files in the
> Program Files\Manufacturer\Product directory.
>
> However, a different user gets access denied to Program Files when the
> restore is attempted. Him being in another country makes this complicated
> to troubleshoot, so I'm wondering if I'm missing some detail in my code
> here. I am running perMachine, and elevated, and set the custom actions to
> deferred. The directory-path sent to the custom action gets sent correctly.
> The backup-file is written correctly to disk by the custom-action. (Please
> ignore the part of the code that writes a .bak-file to disk, it's a
> remnant.) But the failure comes when doing the final step of the
> "installTpdb"-customaction, which is a restore:
>
> 
> http://schemas.microsoft.com/wix/2006/wi"; xmlns:netfx="
> http://schemas.microsoft.com/wix/NetFxExtension";>
>Manufacturer="MyCompanyName" UpgradeCode="myupgradecoderemoved">
>InstallerVersion="200"
>   Compressed="yes"
>   InstallScope="perMachine"
>   InstallPrivileges="elevated"
>   Manufacturer="MyCompanyName"
>   Platform='x86'  />
> 
>  Value="SetupResources/LicenseAgreement.rtf" />
> 
>  Value="SetupResources/WiXDefBannerBitmap.bmp" />
>  Value="SetupResources/WiXDefDialogBitmap.bmp" />
> 
>  DllEntry='InstallTpdb' Execute='deferred'/>
>  DllEntry='TryUpdateTpdb' Execute='deferred' />
>  DllEntry='TryReadTpdb' Execute='deferred' />
>  DllEntry='UninstallTpdb' Execute='deferred' />
>
>  SourceFile='WiX.TPDB.CustomActions.CA.dll' />
>
> 
>  Value="SomeCustomActionDataKey=[INSTALLDIRECTORY]"/>
> 
> 
> 
> 
> 
> 
> 
>   
> 
> 
> 
>   
> 
>KeyPath='yes'/>
> 
>   
>   
> 
>   
>   
> 
>   
> 
>
> 
>  Level="1">
>   
> 
> 
>   
>   NOT
> Installed
>   NOT
> Installed
>   NOT
> Installed
>   (NOT
> UPGRADINGPRODUCTCODE) AND (REMOVE="ALL")
> 
> 
> 
> 
> 
>   
> 
>
> >From the logfile and custom action, it always throws this exception:
>
> Exception thrown by custom action:
> System.Reflection.TargetInvocationException: Exception has been thrown by
> the target of an invocation. ---> System.UnauthorizedAccessException:
> Access to the path 'C:\Program Files (x86)\MyCompanyName\Database WiXTest'
> is denied.
>
> I think I see the problem in the logfile from the client's machine, and it
> is:
>
> MSI (c) (5C:80) [10:10:58:316]: Machine policy value 'DisablePatch' is 0
> MSI (c) (5C:80) [10:10:58:317]: Machine policy value 'AllowLockdownPatch'
> is 0
> MSI (c) (5C:80) [10:10:58:317]: Machine policy value 'DisableMsi' is 0
> MSI (c) (5C:80) [10:10:58:317]: Machine policy value
> 'AlwaysInstallElevated' is 0
> MSI (c) (5C:80) [10:10:58:317]: User policy value 'AlwaysInstallElevated'
> is 0
> MSI (c) (5C:80) [10:10:58:317]: Running product '{myproductcoderemoved}'
> with user privileges: It's not assigned.
>
> On my machine, it says:
>
> MSI (c) (14:40) [10:58:13:252]: Product installation will be elevated
> because user is admin and product is being installed per-machine.
> MSI (c) (14:40) [10:58:13:252]: Running product '{myproductcoderemoved}'
> with elevated privileges: Product is assigned.
>
> The question is, what to do about it? Or any way to work around it? Any
> which way to write to Program Files would be awesome. It really is the most
> convenient for me to be able to write to Program Files during the
> installation. The database backup-file contains data, and there will be
> cases where I need to copy a database from a SQL 2005 server to SQL 2008
> server on the same machine, where backup/restore is the most convenient
> mechanism. I could achieve all things by generating scripts, and generate
> some scripts for transfering data, but I would prefer to do it this way
> because the database-work utilizes tried and tested code that exists in the
> application associated with the database (the application is 

Re: [WiX-users] About DownloadURL

[Rob Mensching]

More specifically, you cannot use RemotePayload element and
Compressed='yes' on the ExePackage element together. That doesn't make
sense and the bug here is that the compiler didn't give you an error
message here saying that. 


On Fri, May 31, 2013 at 5:37 AM, Markus Wehrle  wrote:

> Ok, I see.
> If you want to have the ExePackage compressed into your bootstrapper.exe
> (compressed="yes") you need to specify it using "Source" attribute. Cause
> it
> will be compressed into your boostrapper during compile time, you must not
> declare a DownloadUrl.
> If you specifiy compressed="no" your ExePackage gets downloaded from the
> DownloadUrl during the installation of your boostrapper.
>
>
> > Benjamin Mayrargue  hat am 31. Mai 2013 um 14:03
> > geschrieben:
> >
> >  Sorry, this fails:
> >  Compressed = "yes "
> >   DownloadUrl = " $(var.UrlSauvegarde) "
> >
> >  But this works perfectly:
> >  Compressed = "no "
> >   DownloadUrl = " $(var.UrlSauvegarde) "
> >
> >
> >
> >  http://schemas.microsoft.com/wix/2006/wi>"
> >   xmlns:util=""
> >   xmlns:bal=""
> >
> >   >
> >
> > http://www.vapolia.fr/beta/produitVide1.exe>
> >   ?>
> >
> > > UpgradeCode="BC841679-F636-4098-9EE7-3EAC3F055748"
> >IconSourceFile='media\install.ico'
> >AboutUrl='' Compressed='yes'
> >DisableModify='yes' DisableRemove='yes'>
> >
> >  
> >
> >   
> >
> >
> >
> >  
> > >  Id="Sauvegarde"
> >  InstallCommand=' /S -password="[PASSWORD64]" -user="[EMAIL]"'
> >  PerMachine="yes"
> >  Permanent="yes"
> >  Vital="yes"
> >  Cache="yes"
> >  InstallSize="100"
> >  Name="Sauvegarde.exe"
> >  Compressed="no"
> >  DownloadUrl="$(var.UrlSauvegarde)">
> >   > CertificatePublicKey="D2A6F974A08D42D7795C7AA5440E04E16DDCFD06"
> > CertificateThumbprint="76DD0F11CF7E174ED20F160C3F991E6BF418A6FD"
> > Description="ProduitVide" Hash="C792F08CF024CFB72F6634280D6E647F27C4ABB5"
> > ProductName="ProduitVide" Size="81576" Version="1.0.0.0" />
> >  
> >  
> >  
> >  
> >
> >  
> >
> >
> >  
> >
> >
> >
> >
> >  2013/5/31 Markus Wehrle mailto:mar...@laika42.com>
> >
> >> >Hi Benjamin,
> > >
> > >we do not have this issue and can successul download exe package in
> out
> > > burn configuration.
> > >Can you provide more details, e.g. the complete ExePackage
> definition and
> > > the content of $(var.UrlSauvegarde)?
> > >
> > >
> > >> Benjamin Mayrargue < benja...@vapolia.fr  benja...@vapolia.fr> >
> > >> hat am 31. Mai 2013 um 10:33 geschrieben:
> > >>
> > >>
> > >> Hi all,
> > >> how are you today ?
> > >> It's raining hard here in Paris.
> > >>
> > >> I have found a "bug" in 3.7 :)
> > >>
> > >> If an ExePackage has a DownloadUrl and Compressed is set to yes,
> light
> > >> failed with error LGHT0103: The system cannot find the file ''
> with
> > >> type ''.
> > >>
> > >> Compressed="no"
> > >> DownloadUrl="$(var.UrlSauvegarde)"
> > >>
> > >> The error message should be more explicit :)
> > >>
> > >> B.
> > >>
> --
> > >> Get 100% visibility into Java/.NET code with AppDynamics Lite
> > >> It's a free troubleshooting tool designed for production
> > >> Get down to code-level detail for bottlenecks, with <2% overhead.
> > >> Download for free and get started troubleshooting in minutes.
> > >>
> > >> ___
> > >> WiX-users mailing list
> > >> WiX-users@lists.sourceforge.net
> > >> 
> > >>
> > >  >
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2

Re: [WiX-users] Skip restore point in bootstrapper bundle

[Rob Mensching]

1. I searched the WiX.chm for "restore point" and got one hit on the Chain
element which has an attribute named "DisableSystemRestore". I think
that'll do what you want.

2. Bundles are not Products. Completely different engines and we're trying
to learn from the mistakes of the engines before us.

2a. Bundles don't support Properties they support Variables. They can act
quite similarly but are in completely different namespaces. Thus we
purposefully named them differently to force an understanding that they are
different. Bundle's also don't tend to use "specially named" Variables to
control behavior of the engine. Windows Installer does do that with
Properties (ProductName, ProductVersion, UpgradeCode, ARPSYSTEMCOMPONENT
and ALLUSERS for example) and it's a thing that we've found often causes
confusion. As a result, in the WiX toolset, we're slowly creating strongly
typed constructs to hide the "specially named" Properties (most recent
addition is the Package/@InstallScope that takes care of ALLUSERS and a
couple other things for you correctly). We've tried to solve this correctly
from the beginning with the Burn engine so there aren't Variables to set
that control behavior directly. That said, many strongly typed constructs
are exposed as "built-in" Variables to make it easy for a
BootstrapperApplication to access.

2b. The Burn engine avoids displaying *any* UI today so it doesn't do
general purpose Conditions today. Tremendous amounts of code goes into
trying to allow UI to be customized so the Burn engine just stays out of
the way. The three places Burn shows UI I can think of are:
Bundle/@Condition, the splash screen, Internet proxy password prompt. The
Bundle/@Condition failures display a system message that basically says
this operating system is not supported. It's basically designed so people
can say, "I know Burn will run on Windows XP but my product won't so just
bail." That message shows up in the system UI and is a boring MessageBox().
The splash screen is a bitmap provided by the user. Finally, the proxy
password prompt is an Internet Explorer dialog box shown in very special
cases and only if the BA says it is okay so that's not even really Burn
showing the UI. Thus, the Burn engine doesn't support general purpose
Condition's because there is no localization story and you'd be stuck with,
at best, MessageBox() behavior. Rather than provide that, Burn allows a
BootstrapperApplication to handle all the UI. Thus there is the
bal:Condition which is a condition construct supported by the wixstdba and
that all comes with the BalExtension.


On Fri, May 31, 2013 at 12:15 PM, Alain Forget  wrote:

> I know that  in a  will
> skip the restore point, but how can this also be done in a ?
>
> In general, how do I set properties like that in a bootstrapper?
>
> lso, why can't elements like  and  be used in a
> bootstrapper's  the same way they are for a  in a single
> MSI?
>
> Alain
>
> ***
> Alain Forget, Ph.D.
> Postdoctoral Researcher
> CyLab, Carnegie Mellon University
> afor...@cmu.edu
> http://cups.cs.cmu.edu/~aforget/
> ***
>
>
>
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn and Wixlibs

[Rob Mensching]

I think by "link" John means using a link in Visual Studio to add the file
to multiple projects. Personally, I would use a Library .wixproj to build
reusable chunks which is John's second suggestion.


On Fri, May 31, 2013 at 3:02 PM, Wheeler, Blaine (DSHS/DCS) <
bwhee...@dshs.wa.gov> wrote:

> By link you mean specify the .wxs files on the candle command line?
>
> -Original Message-
> From: John Cooper [mailto:jocoo...@jackhenry.com]
> Sent: Friday, May 31, 2013 2:48 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Burn and Wixlibs
>
> Links or wixlibs.
>
> --
> John Merryweather Cooper
> Build & Install Engineer - ESA
> Jack Henry & Associates, Inc.®
> Shawnee Mission, KS  66227
> Office:  913-341-3434 x791011
> jocoo...@jackhenry.com
> www.jackhenry.com
>
>
>
>
> -Original Message-
> From: Wheeler, Blaine (DSHS/DCS) [mailto:bwhee...@dshs.wa.gov]
> Sent: Friday, May 31, 2013 4:39 PM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: [WiX-users] Burn and Wixlibs
>
> We have about 20 fragments with MSIPackages or EXEPackages in them. I need
> to build several Bundles that have some of these Fragments in common.  How
> can I refer to them without actually having to add the wxs fragments to
> each Bundle project.  It would be handy to have 1 solution, with all of the
> Bundles and references to the fragments.
>
> Can VS2010 reference .wxs files as fragments ?
>
> Example:
> Frag1.wxs
> Frag2.wxs
> Frag3.wxs
>
> Bundle1 has Frag1.wxs, Frag2.wxs, and Frag3.wxs
>
> Bundle2 has Frag1.wxs and Frag3
>
>
> Blaine Wheeler
> Department of Social and Health Services Project Coordinator SEMS
> Operations
> 360.664.5416
> blaine.whee...@dshs.wa.gov
>
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free
> troubleshooting tool designed for production Get down to code-level detail
> for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> NOTICE: This electronic mail message and any files transmitted with it are
> intended exclusively for the individual or entity to which it is addressed.
> The message, together with any attachment, may contain confidential and/or
> privileged information.
> Any unauthorized review, use, printing, saving, copying, disclosure or
> distribution is strictly prohibited. If you have received this message in
> error, please immediately advise the sender by reply email and delete all
> copies.
>
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free
> troubleshooting tool designed for production Get down to code-level detail
> for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] File version always 1.0.0.0

[Rob Mensching]

I downloaded the wix38.exe which uses the latest WiX toolset to build and
it seems to set both of the version numbers correctly. Not sure why you'd
see different behavior. Maybe a bug in an old version of WiX toolset
(assuming your using an older version).


On Fri, May 31, 2013 at 3:26 PM, Alain Forget  wrote:

> When setting my Bundle's version to X.Y.Z (using the Version attribute),
> the resulting .exe's Product Version is correctly X.Y.Z, but looking at the
> .exe's Properties' Details tab (or even hovering over the icon or
> filename), the File Version always seems to display 1.0.0.0 . To my
> knowledge, we don't set anything to 1.0.0.0.
>
> I want the Product and File Versions to match, just to avoid any
> versioning confusion. Does anyone know how to set the File Version?
>
> Alain
>
> ***
> Alain Forget, Ph.D.
> Postdoctoral Researcher
> CyLab, Carnegie Mellon University
> afor...@cmu.edu
> http://cups.cs.cmu.edu/~aforget/
> ***
>
>
>
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] File version always 1.0.0.0

[Alain Forget]

When setting my Bundle's version to X.Y.Z (using the Version attribute), the 
resulting .exe's Product Version is correctly X.Y.Z, but looking at the .exe's 
Properties' Details tab (or even hovering over the icon or filename), the File 
Version always seems to display 1.0.0.0 . To my knowledge, we don't set 
anything to 1.0.0.0. 

I want the Product and File Versions to match, just to avoid any versioning 
confusion. Does anyone know how to set the File Version?

Alain

***
Alain Forget, Ph.D.
Postdoctoral Researcher
CyLab, Carnegie Mellon University
afor...@cmu.edu
http://cups.cs.cmu.edu/~aforget/
***




--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn and Wixlibs

[Wheeler, Blaine (DSHS/DCS)]

By link you mean specify the .wxs files on the candle command line?

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com] 
Sent: Friday, May 31, 2013 2:48 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Burn and Wixlibs

Links or wixlibs.

--
John Merryweather Cooper
Build & Install Engineer - ESA
Jack Henry & Associates, Inc.®
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com 




-Original Message-
From: Wheeler, Blaine (DSHS/DCS) [mailto:bwhee...@dshs.wa.gov]
Sent: Friday, May 31, 2013 4:39 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] Burn and Wixlibs

We have about 20 fragments with MSIPackages or EXEPackages in them. I need to 
build several Bundles that have some of these Fragments in common.  How can I 
refer to them without actually having to add the wxs fragments to each Bundle 
project.  It would be handy to have 1 solution, with all of the Bundles and 
references to the fragments.

Can VS2010 reference .wxs files as fragments ?

Example:
Frag1.wxs
Frag2.wxs
Frag3.wxs

Bundle1 has Frag1.wxs, Frag2.wxs, and Frag3.wxs

Bundle2 has Frag1.wxs and Frag3


Blaine Wheeler
Department of Social and Health Services Project Coordinator SEMS Operations
360.664.5416
blaine.whee...@dshs.wa.gov


--
Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free 
troubleshooting tool designed for production Get down to code-level detail for 
bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are 
intended exclusively for the individual or entity to which it is addressed. The 
message, together with any attachment, may contain confidential and/or 
privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution is strictly prohibited. If you have received this message in 
error, please immediately advise the sender by reply email and delete all 
copies.


--
Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free 
troubleshooting tool designed for production Get down to code-level detail for 
bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn and Wixlibs

[John Cooper]

Links or wixlibs.

--
John Merryweather Cooper
Build & Install Engineer - ESA
Jack Henry & Associates, Inc.®
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com 




-Original Message-
From: Wheeler, Blaine (DSHS/DCS) [mailto:bwhee...@dshs.wa.gov] 
Sent: Friday, May 31, 2013 4:39 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] Burn and Wixlibs

We have about 20 fragments with MSIPackages or EXEPackages in them. I need to 
build several Bundles that have some of these Fragments in common.  How can I 
refer to them without actually having to add the wxs fragments to each Bundle 
project.  It would be handy to have 1 solution, with all of the Bundles and 
references to the fragments.

Can VS2010 reference .wxs files as fragments ?

Example:
Frag1.wxs
Frag2.wxs
Frag3.wxs

Bundle1 has Frag1.wxs, Frag2.wxs, and Frag3.wxs

Bundle2 has Frag1.wxs and Frag3


Blaine Wheeler
Department of Social and Health Services Project Coordinator SEMS Operations
360.664.5416
blaine.whee...@dshs.wa.gov


--
Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free 
troubleshooting tool designed for production Get down to code-level detail for 
bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Burn and Wixlibs

[Wheeler, Blaine (DSHS/DCS)]

We have about 20 fragments with MSIPackages or EXEPackages in them. I need to 
build several Bundles that have some of these Fragments in common.  How can I 
refer to them without actually having to add the wxs fragments to each Bundle 
project.  It would be handy to have 1 solution, with all of the Bundles and 
references to the fragments.

Can VS2010 reference .wxs files as fragments ?

Example:
Frag1.wxs
Frag2.wxs
Frag3.wxs

Bundle1 has Frag1.wxs, Frag2.wxs, and Frag3.wxs

Bundle2 has Frag1.wxs and Frag3


Blaine Wheeler
Department of Social and Health Services
Project Coordinator
SEMS Operations
360.664.5416
blaine.whee...@dshs.wa.gov


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] *Package Permanent attribute

[Wesley Manning]

Correct.  I should be more precise.  A bundle contains burn engine and packages.

From: Edwin Castro [mailto:egca...@gmail.com]
Sent: May-31-13 4:51 PM
To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.
Cc: Wesley Manning
Subject: Re: [WiX-users] *Package Permanent attribute

My understanding is that a Bundle is processed by the "burn" engine.

ARP == Add/Remove Programs

On Fri, May 31, 2013 at 12:44 PM, Alain Forget 
mailto:afor...@cmu.edu>> wrote:
By "burn", you mean what I'm referring to as the Bundle?

And by ARP, you mean "Add/Remove Programs"?

Just making sure I understand. :-)

Alain

-Original Message-
From: Wesley Manning [mailto:wmann...@dynagen.ca]
Sent: May 31, 2013 15:41
To: afor...@cmu.edu; General discussion for Windows 
Installer XML toolset.
Subject: RE: [WiX-users] *Package Permanent attribute

Just means burn will not try to uninstall it. The package will also appear in 
ARP.

-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: May-31-13 4:37 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] *Package Permanent attribute

Can someone please clarify the effect of the Permanent attribute for a package 
(e.g. MsiPackage, ExePackage)?

The documentation 
(http://wix.sourceforge.net/manual-wix3/wix_xsd_msipackage.htm) says, 
"Specifies whether the package can be uninstalled. The default is 'no'."

Making a package impossible to uninstall seems extremely frustrating for a 
user, and in my own MsiPackage, when Permanent='yes', I can still uninstall it, 
so...I don't think I understand what it does.

Alain

***
Alain Forget, Ph.D.
Postdoctoral Researcher
CyLab, Carnegie Mellon University
afor...@cmu.edu
http://cups.cs.cmu.edu/~aforget/
***




--
Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free 
troubleshooting tool designed for production Get down to code-level detail for 
bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Edwin G. Castro
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] *Package Permanent attribute

[Alain Forget]

Yeah, I'm new to burn (and WiX in general), so I'm still getting the lingo 
down. Thanks!

-Original Message-
From: Edwin Castro [mailto:egca...@gmail.com] 
Sent: May 31, 2013 15:51
To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.
Cc: Wesley Manning
Subject: Re: [WiX-users] *Package Permanent attribute

My understanding is that a Bundle is processed by the "burn" engine.

ARP == Add/Remove Programs


On Fri, May 31, 2013 at 12:44 PM, Alain Forget  wrote:


By "burn", you mean what I'm referring to as the Bundle?

And by ARP, you mean "Add/Remove Programs"?

Just making sure I understand. :-)

Alain


-Original Message-
From: Wesley Manning [mailto:wmann...@dynagen.ca]
Sent: May 31, 2013 15:41
To: afor...@cmu.edu; General discussion for Windows Installer XML 
toolset.
Subject: RE: [WiX-users] *Package Permanent attribute

Just means burn will not try to uninstall it. The package will also 
appear in ARP.

-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: May-31-13 4:37 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] *Package Permanent attribute

Can someone please clarify the effect of the Permanent attribute for a 
package (e.g. MsiPackage, ExePackage)?

The documentation 
(http://wix.sourceforge.net/manual-wix3/wix_xsd_msipackage.htm) says, 
"Specifies whether the package can be uninstalled. The default is 'no'."

Making a package impossible to uninstall seems extremely frustrating 
for a user, and in my own MsiPackage, when Permanent='yes', I can still 
uninstall it, so...I don't think I understand what it does.

Alain

***
Alain Forget, Ph.D.
Postdoctoral Researcher
CyLab, Carnegie Mellon University
afor...@cmu.edu
http://cups.cs.cmu.edu/~aforget/
***





--
Get 100% visibility into Java/.NET code with AppDynamics Lite It's a 
free troubleshooting tool designed for production Get down to code-level detail 
for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users




--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users





-- 
Edwin G. Castro



--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] *Package Permanent attribute

[Edwin Castro]

My understanding is that a Bundle is processed by the "burn" engine.

ARP == Add/Remove Programs


On Fri, May 31, 2013 at 12:44 PM, Alain Forget  wrote:

> By "burn", you mean what I'm referring to as the Bundle?
>
> And by ARP, you mean "Add/Remove Programs"?
>
> Just making sure I understand. :-)
>
> Alain
>
> -Original Message-
> From: Wesley Manning [mailto:wmann...@dynagen.ca]
> Sent: May 31, 2013 15:41
> To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.
> Subject: RE: [WiX-users] *Package Permanent attribute
>
> Just means burn will not try to uninstall it. The package will also appear
> in ARP.
>
> -Original Message-
> From: Alain Forget [mailto:afor...@cmu.edu]
> Sent: May-31-13 4:37 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] *Package Permanent attribute
>
> Can someone please clarify the effect of the Permanent attribute for a
> package (e.g. MsiPackage, ExePackage)?
>
> The documentation (
> http://wix.sourceforge.net/manual-wix3/wix_xsd_msipackage.htm) says,
> "Specifies whether the package can be uninstalled. The default is 'no'."
>
> Making a package impossible to uninstall seems extremely frustrating for a
> user, and in my own MsiPackage, when Permanent='yes', I can still uninstall
> it, so...I don't think I understand what it does.
>
> Alain
>
> ***
> Alain Forget, Ph.D.
> Postdoctoral Researcher
> CyLab, Carnegie Mellon University
> afor...@cmu.edu
> http://cups.cs.cmu.edu/~aforget/
> ***
>
>
>
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free
> troubleshooting tool designed for production Get down to code-level detail
> for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
Edwin G. Castro
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] *Package Permanent attribute

[Alain Forget]

By "burn", you mean what I'm referring to as the Bundle?

And by ARP, you mean "Add/Remove Programs"?

Just making sure I understand. :-)

Alain

-Original Message-
From: Wesley Manning [mailto:wmann...@dynagen.ca] 
Sent: May 31, 2013 15:41
To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] *Package Permanent attribute

Just means burn will not try to uninstall it. The package will also appear in 
ARP.

-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu] 
Sent: May-31-13 4:37 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] *Package Permanent attribute

Can someone please clarify the effect of the Permanent attribute for a package 
(e.g. MsiPackage, ExePackage)?

The documentation 
(http://wix.sourceforge.net/manual-wix3/wix_xsd_msipackage.htm) says, 
"Specifies whether the package can be uninstalled. The default is 'no'."

Making a package impossible to uninstall seems extremely frustrating for a 
user, and in my own MsiPackage, when Permanent='yes', I can still uninstall it, 
so...I don't think I understand what it does.

Alain

***
Alain Forget, Ph.D.
Postdoctoral Researcher
CyLab, Carnegie Mellon University
afor...@cmu.edu
http://cups.cs.cmu.edu/~aforget/
***




--
Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free 
troubleshooting tool designed for production Get down to code-level detail for 
bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix dev and regular dev best practices

[Alain Forget]

+1

The chasm between getting things working in a development environment and 
getting them working seamlessly in the deployment environment (by end users) is 
a lot wider than some may be willing to admit.

Alain

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com] 
Sent: May 31, 2013 15:36
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix dev and regular dev best practices

If it doesn't get built, it won't get tested.  Period.

Dev's have a tendency to consider installer building a waste of time (they 
always think they can do it better with a 3rd-party zip lib and some sort of 
XML config document) until it's one week before beta and suddenly you need to 
shake the bugs out of code that should've been tested since the beginning of 
the iteration six months prior.

Push back HARD on any suggestion that building the installer is expendable.  
It's one of Wix's greatest strengths, and the installer is the first view a 
consumer will get of your product.  If it isn't a good impression, it will have 
disproportionate impact.

--
John Merryweather Cooper
Build & Install Engineer - ESA
Jack Henry & Associates, Inc.®
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com 




-Original Message-
From: Drake, David [mailto:david.dr...@wizards.com]
Sent: Friday, May 31, 2013 1:39 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix dev and regular dev best practices

Albert,
Do you require your regular code writing devs to install Wix on their boxes so 
they don't get errors opening the wixproj files in the main solution, or do you 
keep the .wixproj files off in their own little solution so the devs don't 
notice?  Also, do your devs handle the installers, or does someone other than 
the main app coders do that?

Thanks,
~David

-Original Message-
From: Albert van Peppen [mailto:alb...@insad.nl]
Sent: Thursday, May 30, 2013 23:52 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix dev and regular dev best practices

We use a lot of (VS) Project Property Sheets. For WiX we have defined several 
property sheets for this. Our solution gives us the possibility to change the 
location where WixTools are etc. This way we can easily switch between WiX 
versions as well (assuming the schema, on what we use, hasn't been broken)

Just my 2 ct ;)

Best regards,

Albert van Peppen

-Oorspronkelijk bericht-
Van: John Ludlow [mailto:john.ludlow...@gmail.com]
Verzonden: 30 May 2013 17:06
Aan: General discussion for Windows Installer XML toolset.
Onderwerp: Re: [WiX-users] Wix dev and regular dev best practices

@Mark:

Yep, that's what we've gone with, but we had issues getting the right set of 
properties to set up the paths properly because there's a number of cascading 
properties. Also, we had issues in that we have to do this with every .wixproj. 
(I guess we might create a customized .wixproj which has those changes already)

Thanks


On 30 May 2013 15:28, Freedman, Mark P.  wrote:

> I've recently added WiX to my continuous integration server, Team City.
> They key is to not have to install stuff on the build machines. WiX 
> includes the install binaries that can be put right in your source tree.
> However the binaries do not include the files necessary for Custom 
> Actions (CAs), so I had to include some extra files that come with the 
> standard WiX developer install.
>
> http://wix.codeplex.com/releases/view/99514
>
> Then, update your .wixproj projects to point to the relative path to 
> your wix binaries. See the Wix tags in .
>
>   
> Debug
> x86
> 3.7
> z
> 2.0
> My  Installer
> Package
> ..\..\InstallTools\wix\3.7.1224.0\
> $(WixToolPath)Wix.targets
> wixtasks.dll
>   
>
>
> If you're doing bootstrappers prerequisites with the 
> GenerateBootstrapper command, you can do something similar in your 
> project's bootstrapper to redirect them to a  relative path so that 
> the build machine doesn't need to have Visual Studio installed, or 
> whatever puts them in the default Microsoft SDK package.
>
>  ApplicationName="My App " BootstrapperItems="@(BootstrapperFile)"
> ComponentsLocation="Relative" CopyComponents="True"
> OutputPath="$(OutputPath)" Path="..\..\Bootstrapper" />
>
> Mark Freedman
>
>
> -Original Message-
> From: John Ludlow [mailto:john.ludlow...@gmail.com]
> Sent: Thursday, May 30, 2013 5:53 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Wix dev and regular dev best practices
>
> We're looking at simply making WiX part of the toolkit you need to 
> build our solutions.  We've tried this with some smaller projects and 
> it's worked really well. Developers can follow up on their own 
> impacts, and they can tell when they've broken the install. This 
> increases build quality and frees up install develo

Re: [WiX-users] *Package Permanent attribute

[Wesley Manning]

Just means burn will not try to uninstall it. The package will also appear in 
ARP.

-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu] 
Sent: May-31-13 4:37 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] *Package Permanent attribute

Can someone please clarify the effect of the Permanent attribute for a package 
(e.g. MsiPackage, ExePackage)?

The documentation 
(http://wix.sourceforge.net/manual-wix3/wix_xsd_msipackage.htm) says, 
"Specifies whether the package can be uninstalled. The default is 'no'."

Making a package impossible to uninstall seems extremely frustrating for a 
user, and in my own MsiPackage, when Permanent='yes', I can still uninstall it, 
so...I don't think I understand what it does.

Alain

***
Alain Forget, Ph.D.
Postdoctoral Researcher
CyLab, Carnegie Mellon University
afor...@cmu.edu
http://cups.cs.cmu.edu/~aforget/
***




--
Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free 
troubleshooting tool designed for production Get down to code-level detail for 
bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix dev and regular dev best practices

[John Cooper]

If it doesn't get built, it won't get tested.  Period.

Dev's have a tendency to consider installer building a waste of time (they 
always think they can do it better with a 3rd-party zip lib and some sort of 
XML config document) until it's one week before beta and suddenly you need to 
shake the bugs out of code that should've been tested since the beginning of 
the iteration six months prior.

Push back HARD on any suggestion that building the installer is expendable.  
It's one of Wix's greatest strengths, and the installer is the first view a 
consumer will get of your product.  If it isn't a good impression, it will have 
disproportionate impact.

--
John Merryweather Cooper
Build & Install Engineer - ESA
Jack Henry & Associates, Inc.®
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com 




-Original Message-
From: Drake, David [mailto:david.dr...@wizards.com] 
Sent: Friday, May 31, 2013 1:39 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix dev and regular dev best practices

Albert,
Do you require your regular code writing devs to install Wix on their boxes so 
they don't get errors opening the wixproj files in the main solution, or do you 
keep the .wixproj files off in their own little solution so the devs don't 
notice?  Also, do your devs handle the installers, or does someone other than 
the main app coders do that?

Thanks,
~David

-Original Message-
From: Albert van Peppen [mailto:alb...@insad.nl]
Sent: Thursday, May 30, 2013 23:52 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix dev and regular dev best practices

We use a lot of (VS) Project Property Sheets. For WiX we have defined several 
property sheets for this. Our solution gives us the possibility to change the 
location where WixTools are etc. This way we can easily switch between WiX 
versions as well (assuming the schema, on what we use, hasn't been broken)

Just my 2 ct ;)

Best regards,

Albert van Peppen

-Oorspronkelijk bericht-
Van: John Ludlow [mailto:john.ludlow...@gmail.com]
Verzonden: 30 May 2013 17:06
Aan: General discussion for Windows Installer XML toolset.
Onderwerp: Re: [WiX-users] Wix dev and regular dev best practices

@Mark:

Yep, that's what we've gone with, but we had issues getting the right set of 
properties to set up the paths properly because there's a number of cascading 
properties. Also, we had issues in that we have to do this with every .wixproj. 
(I guess we might create a customized .wixproj which has those changes already)

Thanks


On 30 May 2013 15:28, Freedman, Mark P.  wrote:

> I've recently added WiX to my continuous integration server, Team City.
> They key is to not have to install stuff on the build machines. WiX 
> includes the install binaries that can be put right in your source tree.
> However the binaries do not include the files necessary for Custom 
> Actions (CAs), so I had to include some extra files that come with the 
> standard WiX developer install.
>
> http://wix.codeplex.com/releases/view/99514
>
> Then, update your .wixproj projects to point to the relative path to 
> your wix binaries. See the Wix tags in .
>
>   
> Debug
> x86
> 3.7
> z
> 2.0
> My  Installer
> Package
> ..\..\InstallTools\wix\3.7.1224.0\
> $(WixToolPath)Wix.targets
> wixtasks.dll
>   
>
>
> If you're doing bootstrappers prerequisites with the 
> GenerateBootstrapper command, you can do something similar in your 
> project's bootstrapper to redirect them to a  relative path so that 
> the build machine doesn't need to have Visual Studio installed, or 
> whatever puts them in the default Microsoft SDK package.
>
>  ApplicationName="My App " BootstrapperItems="@(BootstrapperFile)"
> ComponentsLocation="Relative" CopyComponents="True"
> OutputPath="$(OutputPath)" Path="..\..\Bootstrapper" />
>
> Mark Freedman
>
>
> -Original Message-
> From: John Ludlow [mailto:john.ludlow...@gmail.com]
> Sent: Thursday, May 30, 2013 5:53 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Wix dev and regular dev best practices
>
> We're looking at simply making WiX part of the toolkit you need to 
> build our solutions.  We've tried this with some smaller projects and 
> it's worked really well. Developers can follow up on their own 
> impacts, and they can tell when they've broken the install. This 
> increases build quality and frees up install developers from the "add a file, 
> remove a file"
> monkey-work we seem to spend 80% of our time doing.
>
> Some of the developers grumbled a bit, but it's also been taken 
> positively by others, and everyone gets a bit more respect for their 
> poor, abused install developers. :)
>
> In fact, the main issues are related to integrating it into our build 
> system (which is more down to the fact that we don't want to install 
> stuff onto ou

[WiX-users] *Package Permanent attribute

[Alain Forget]

Can someone please clarify the effect of the Permanent attribute for a package 
(e.g. MsiPackage, ExePackage)?

The documentation 
(http://wix.sourceforge.net/manual-wix3/wix_xsd_msipackage.htm) says, 
"Specifies whether the package can be uninstalled. The default is 'no'."

Making a package impossible to uninstall seems extremely frustrating for a 
user, and in my own MsiPackage, when Permanent='yes', I can still uninstall it, 
so...I don't think I understand what it does.

Alain

***
Alain Forget, Ph.D.
Postdoctoral Researcher
CyLab, Carnegie Mellon University
afor...@cmu.edu
http://cups.cs.cmu.edu/~aforget/
***




--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Skip restore point in bootstrapper bundle

[Alain Forget]

I know that  in a  will skip 
the restore point, but how can this also be done in a ?

In general, how do I set properties like that in a bootstrapper? 

lso, why can't elements like  and  be used in a 
bootstrapper's  the same way they are for a  in a single MSI?

Alain

***
Alain Forget, Ph.D.
Postdoctoral Researcher
CyLab, Carnegie Mellon University
afor...@cmu.edu
http://cups.cs.cmu.edu/~aforget/
***




--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix dev and regular dev best practices

[Drake, David]

Albert,
Do you require your regular code writing devs to install Wix on their boxes so 
they don't get errors opening the wixproj files in the main solution, or do you 
keep the .wixproj files off in their own little solution so the devs don't 
notice?  Also, do your devs handle the installers, or does someone other than 
the main app coders do that?

Thanks,
~David

-Original Message-
From: Albert van Peppen [mailto:alb...@insad.nl] 
Sent: Thursday, May 30, 2013 23:52 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix dev and regular dev best practices

We use a lot of (VS) Project Property Sheets. For WiX we have defined several 
property sheets for this. Our solution gives us the possibility to change the 
location where WixTools are etc. This way we can easily switch between WiX 
versions as well (assuming the schema, on what we use, hasn't been broken)

Just my 2 ct ;)

Best regards,

Albert van Peppen

-Oorspronkelijk bericht-
Van: John Ludlow [mailto:john.ludlow...@gmail.com]
Verzonden: 30 May 2013 17:06
Aan: General discussion for Windows Installer XML toolset.
Onderwerp: Re: [WiX-users] Wix dev and regular dev best practices

@Mark:

Yep, that's what we've gone with, but we had issues getting the right set of 
properties to set up the paths properly because there's a number of cascading 
properties. Also, we had issues in that we have to do this with every .wixproj. 
(I guess we might create a customized .wixproj which has those changes already)

Thanks


On 30 May 2013 15:28, Freedman, Mark P.  wrote:

> I've recently added WiX to my continuous integration server, Team City.
> They key is to not have to install stuff on the build machines. WiX 
> includes the install binaries that can be put right in your source tree.
> However the binaries do not include the files necessary for Custom 
> Actions (CAs), so I had to include some extra files that come with the 
> standard WiX developer install.
>
> http://wix.codeplex.com/releases/view/99514
>
> Then, update your .wixproj projects to point to the relative path to 
> your wix binaries. See the Wix tags in .
>
>   
> Debug
> x86
> 3.7
> z
> 2.0
> My  Installer
> Package
> ..\..\InstallTools\wix\3.7.1224.0\
> $(WixToolPath)Wix.targets
> wixtasks.dll
>   
>
>
> If you're doing bootstrappers prerequisites with the 
> GenerateBootstrapper command, you can do something similar in your 
> project's bootstrapper to redirect them to a  relative path so that 
> the build machine doesn't need to have Visual Studio installed, or 
> whatever puts them in the default Microsoft SDK package.
>
>  ApplicationName="My App " BootstrapperItems="@(BootstrapperFile)"
> ComponentsLocation="Relative" CopyComponents="True"
> OutputPath="$(OutputPath)" Path="..\..\Bootstrapper" />
>
> Mark Freedman
>
>
> -Original Message-
> From: John Ludlow [mailto:john.ludlow...@gmail.com]
> Sent: Thursday, May 30, 2013 5:53 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Wix dev and regular dev best practices
>
> We're looking at simply making WiX part of the toolkit you need to 
> build our solutions.  We've tried this with some smaller projects and 
> it's worked really well. Developers can follow up on their own 
> impacts, and they can tell when they've broken the install. This 
> increases build quality and frees up install developers from the "add a file, 
> remove a file"
> monkey-work we seem to spend 80% of our time doing.
>
> Some of the developers grumbled a bit, but it's also been taken 
> positively by others, and everyone gets a bit more respect for their 
> poor, abused install developers. :)
>
> In fact, the main issues are related to integrating it into our build 
> system (which is more down to the fact that we don't want to install 
> stuff onto our build system - we want the build to be able to xcopy 
> install whatever it needs).
>
>
>
>
>
> On 29 May 2013 18:46,  wrote:
>
> > I don't know if our approach will work well long term since we are 
> > still developing all of this, but we decided we'd build front end 
> > utilities for developers to use with presets implicitly written out 
> > to wxs for them (like Manufacturer and expected directories to 
> > install to, etc.). This way in principle we could also have 
> > developers (or in your case, a build server) drop off their files 
> > and an installer build person / process can then pick them up with the 
> > front end to WIX.
> >
> >
> >
> > Keith Douglas
> > Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
> > Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A
> > 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 
> > Facsimile | Télécopieur 613-951-1966 Government of Canada | 
> > Gouvernement du Canada
> >
> >
> > -Original Message-
> > From: Drake, David [mailto:david.dr...@wizards.com]
> > Sent:

Re: [WiX-users] Using WiX Extended Bootstrapper Application without Visual Studio

[Alain Forget]

Bingo. I had no idea I could pass the path to a DLL as an extension to candle & 
light, like this:

candle.exe -ext ./lib/WixBalExtensionExt.dll -ext WixUIExtension -ext 
WixUtilExtension MyBundle.wxs

Somehow, I had thought only pre-packaged extensions could be referenced with 
-ext...although typing that out now, I realise how ridiculous that idea was. 
What good would extension functionality be if it couldn't reference external 
stuff? :-P

Thanks!
Alain

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] 
Sent: May 31, 2013 12:54
To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] Using WiX Extended Bootstrapper Application without 
Visual Studio

If you are doing this via the command line, I assume it's light complaining 
about the extension.  You need to use -ext WixBalExtension (subst whatever 
Neil's is here , probably need a full path) Also, in your wxs you want  to 
include references to any custom extensions (Ex: 
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension";) on the Wix element.

Ref: http://wix.sourceforge.net/manual-wix3/extension_usage_introduction.htm

-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Friday, May 31, 2013 11:21 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Using WiX Extended Bootstrapper Application without Visual 
Studio

My bootstrapper UI has some weird artifacts I want to fix, and Neil 
Sleightholm's WiX Extended Bootstrapper Application (ExtBA, 
http://wixextba.codeplex.com/) seems to provide a more easily customisable UI 
than the native WiX bootstrapper application UI (from what I can gather...if 
there is documentation somewhere about customising the UI without having to 
completely roll my own, I'd love to see it).

To use the ExtBA, Neil says, "Add a reference to WixBalExtensionExt.dll in your 
Visual Studio project..." However, I am not using VS, and so it is unclear how 
I can reference the ExtBA. For example, the example Bundle5.wxs shows this: 



But WiX complains about the unresolved reference, and I can't figure out how to 
tell WiX that this refers to something in the WixBalExtensionExt.dll . So then 
I tried this instead:



WiX then complains that there needs to be at least one Payload specified for a 
BootstrapperApplication, but I'm not sure what to specify as a Payload.

There also doesn't seem to be a way to point to a DLL from the command line. I 
tried the candle.exe -IWixBalExtensionExt.dll to no avail.

I've also tried this, which compiles, but when executing the bundled installer, 
does nothing:





I then added  , but it still can't find 
the reference.

Anyway, I've tried more stabbing in the dark, and not many results. Does anyone 
have experience with either using ExtBA outside of VS or referencing DLLs for 
WiX bootstrapper applications?

Alain

***
Alain Forget, Ph.D.
Postdoctoral Researcher
CyLab, Carnegie Mellon University
afor...@cmu.edu
http://cups.cs.cmu.edu/~aforget/
***




--
Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free 
troubleshooting tool designed for production Get down to code-level detail for 
bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Using WiX Extended Bootstrapper Application without Visual Studio

[Hoover, Jacob]

If you are doing this via the command line, I assume it's light complaining 
about the extension.  You need to use -ext WixBalExtension (subst whatever 
Neil's is here , probably need a full path)
Also, in your wxs you want  to include references to any custom extensions (Ex: 
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension";) on the Wix element.

Ref: http://wix.sourceforge.net/manual-wix3/extension_usage_introduction.htm

-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu] 
Sent: Friday, May 31, 2013 11:21 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Using WiX Extended Bootstrapper Application without Visual 
Studio

My bootstrapper UI has some weird artifacts I want to fix, and Neil 
Sleightholm's WiX Extended Bootstrapper Application (ExtBA, 
http://wixextba.codeplex.com/) seems to provide a more easily customisable UI 
than the native WiX bootstrapper application UI (from what I can gather...if 
there is documentation somewhere about customising the UI without having to 
completely roll my own, I'd love to see it).

To use the ExtBA, Neil says, "Add a reference to WixBalExtensionExt.dll in your 
Visual Studio project..." However, I am not using VS, and so it is unclear how 
I can reference the ExtBA. For example, the example Bundle5.wxs shows this: 



But WiX complains about the unresolved reference, and I can't figure out how to 
tell WiX that this refers to something in the WixBalExtensionExt.dll . So then 
I tried this instead:



WiX then complains that there needs to be at least one Payload specified for a 
BootstrapperApplication, but I'm not sure what to specify as a Payload.

There also doesn't seem to be a way to point to a DLL from the command line. I 
tried the candle.exe -IWixBalExtensionExt.dll to no avail.

I've also tried this, which compiles, but when executing the bundled installer, 
does nothing:





I then added  , but it still can't find 
the reference.

Anyway, I've tried more stabbing in the dark, and not many results. Does anyone 
have experience with either using ExtBA outside of VS or referencing DLLs for 
WiX bootstrapper applications?

Alain

***
Alain Forget, Ph.D.
Postdoctoral Researcher
CyLab, Carnegie Mellon University
afor...@cmu.edu
http://cups.cs.cmu.edu/~aforget/
***




--
Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free 
troubleshooting tool designed for production Get down to code-level detail for 
bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Using WiX Extended Bootstrapper Application without Visual Studio

[Alain Forget]

My bootstrapper UI has some weird artifacts I want to fix, and Neil 
Sleightholm's WiX Extended Bootstrapper Application (ExtBA, 
http://wixextba.codeplex.com/) seems to provide a more easily customisable UI 
than the native WiX bootstrapper application UI (from what I can gather...if 
there is documentation somewhere about customising the UI without having to 
completely roll my own, I'd love to see it).

To use the ExtBA, Neil says, "Add a reference to WixBalExtensionExt.dll in your 
Visual Studio project..." However, I am not using VS, and so it is unclear how 
I can reference the ExtBA. For example, the example Bundle5.wxs shows this: 



But WiX complains about the unresolved reference, and I can't figure out how to 
tell WiX that this refers to something in the WixBalExtensionExt.dll . So then 
I tried this instead:



WiX then complains that there needs to be at least one Payload specified for a 
BootstrapperApplication, but I'm not sure what to specify as a Payload.

There also doesn't seem to be a way to point to a DLL from the command line. I 
tried the candle.exe -IWixBalExtensionExt.dll to no avail.

I've also tried this, which compiles, but when executing the bundled installer, 
does nothing:





I then added  , but it still can't find 
the reference.

Anyway, I've tried more stabbing in the dark, and not many results. Does anyone 
have experience with either using ExtBA outside of VS or referencing DLLs for 
WiX bootstrapper applications?

Alain

***
Alain Forget, Ph.D.
Postdoctoral Researcher
CyLab, Carnegie Mellon University
afor...@cmu.edu
http://cups.cs.cmu.edu/~aforget/
***




--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Windows 8 Resolution of variable written to registry

[Rob Mensching]

I'd recommend starting with a verbose log file to see what is different on
Win8.


On Fri, May 31, 2013 at 7:45 AM, Martin Johnson  wrote:

> The following code snippet works on all OS with the exception of WIndows
> 8.  e.g. on Windows 7 ExcelHelpPath32 has a correctly formatted path to the
> help file and TSDataDirectory has a correctly formatted path to the data
> Directory, On Windows 8 ExcelHelpPath32 is again correctly formatted whilst
> TSDataDirectory has the string [INSTALLDIRDATA].  I have removed some lines
> for clarity because I have 10 registry entries 5 work and 5 don't.
>
> I have looked for any issues reported on Windows 8 installations but can't
> find anything, anyone got a clue what is going on?
>
>Guid="DED812D4-E24B-4154-BF18-EFC6C1A0B0CD">
>
>
> 
>
>  Key='Software\Product\2\SystemConfiguration'
>
>
>  Root='HKCU'
>
>
>  ForceDeleteOnUninstall='yes'>
>
>
> additional lines removed
>
>
>   
>
>  Name='ExcelHelpPath32'
>
>
>  Type='string' Value='[PRODUCTLOCATION]Help.chm'
> KeyPath ='no' />
>
>
> 
>
>  Name='TSDataDirectory'
>
>
>  Type='string'
>
>
>  Value='[INSTALLDIRDATA]'
>
>
>   KeyPath ='no' />
>
>
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ExePackage: rename exe before runnning it

[Rob Mensching]

If the name doesn't match the Payload name, the file will not be cleaned
out of the package cache correctly. I suppose you could mark the ExePackage
as Cache='no' but then you'll want to avoid repairing and uninstalling it
because you'd end up with a prompt for source during uninstall.

All of this is quite complicated. I don't have too much of an issue with
their design as *one* option but they really need to also support passing
the serial number as a parameter.


On Fri, May 31, 2013 at 8:40 AM, Benjamin Mayrargue wrote:

> Is the payload file extracted in the same folder as the stub.exe from the
> ExePackage ?
>
>
> 2013/5/31 Hoover, Jacob 
>
> > Sounds like you need to talk to the person who thought of this "great"
> way
> > of passing a parameter to their installer
> >
> > That being said, you could create a stub exe, which takes the params and
> > does this dance for you. I'd suggest making a copy in the temp folder for
> > the install, and leaving what burn caches alone.  You'd change your
> > ExePackage to reference your stub, and have the real installer exe as a
> > Payload element.
> >
> > You'd have to handle all of the commands for install, uninstall, repair,
> > etc as params to your stub exe.
> >
> > A lot of work, just because a 3rd party installer had a non-standard
> idea.
> >
> > -Original Message-
> > From: Benjamin Mayrargue [mailto:benja...@vapolia.fr]
> > Sent: Friday, May 31, 2013 9:59 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] ExePackage: rename exe before runnning it
> >
> > I need this feature because i'm launching an external installer (.exe)
> and
> > i need to give it a serial number (user dependent, asked in the
> > bootstrapper UI) as parameter, and the only way to give it this parameter
> > is by renaming this exe file from INSTALLER.EXE to INSTALLER_SERIAL.exe
> Yes
> > i know this is completely silly, but i don't have the hand on it.
> >
> > If i include it as a bootstrapper payload, is there a way to get it's
> > pathname ? If yes, i'll run it manually (i don't need to track it).
> > Or maybe by creating a msiPackage, or a custom action i can do it. I
> don't
> > know the easiest way.
> > Or last way, i create a windows exe which takes the correct parameters
> (as
> > real parameters) and does the renaming / execution / and renaming back
> for
> > wix.
> >
> > B.
> >
> >
> >
> > 2013/5/31 Rob Mensching 
> >
> > > No, and that won't work will with the way that Burn caches packages
> > > and such. This scenario isn't supported today. Why do you need to do
> > > such a thing?
> > >
> > >
> > > On Fri, May 31, 2013 at 5:08 AM, Benjamin Mayrargue
> > >  > > >wrote:
> > >
> > > > Hi all again,
> > > > i have a strange requirement.
> > > >
> > > > I need to rename the EXE file (set in ExePackage) before running it.
> > > > The renaming involves a variable set and known only at runtime.
> > > > Is this possible out of the box ?
> > > >
> > > > thks,
> > > > B.
> > > >
> > > >
> > > --
> > > 
> > > > Get 100% visibility into Java/.NET code with AppDynamics Lite It's a
> > > > free troubleshooting tool designed for production Get down to
> > > > code-level detail for bottlenecks, with <2% overhead.
> > > > Download for free and get started troubleshooting in minutes.
> > > > http://p.sf.net/sfu/appdyn_d2d_ap2
> > > > ___
> > > > WiX-users mailing list
> > > > WiX-users@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > > >
> > > >
> > >
> > > --
> > >  Get 100% visibility into Java/.NET code with AppDynamics Lite
> > > It's a free troubleshooting tool designed for production Get down to
> > > code-level detail for bottlenecks, with <2% overhead.
> > > Download for free and get started troubleshooting in minutes.
> > > http://p.sf.net/sfu/appdyn_d2d_ap2
> > > ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> >
> >
> --
> > Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free
> > troubleshooting tool designed for production Get down to code-level
> detail
> > for bottlenecks, with <2% overhead.
> > Download for free and get started troubleshooting in minutes.
> > http://p.sf.net/sfu/appdyn_d2d_ap2
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> >
> --
> > Get 100% visibility into Java/.NET code with AppDynamics Lite
> > It's a free troubleshooting tool desi

Re: [WiX-users] ExePackage: rename exe before runnning it

[Benjamin Mayrargue]

Is the payload file extracted in the same folder as the stub.exe from the
ExePackage ?


2013/5/31 Hoover, Jacob 

> Sounds like you need to talk to the person who thought of this "great" way
> of passing a parameter to their installer
>
> That being said, you could create a stub exe, which takes the params and
> does this dance for you. I'd suggest making a copy in the temp folder for
> the install, and leaving what burn caches alone.  You'd change your
> ExePackage to reference your stub, and have the real installer exe as a
> Payload element.
>
> You'd have to handle all of the commands for install, uninstall, repair,
> etc as params to your stub exe.
>
> A lot of work, just because a 3rd party installer had a non-standard idea.
>
> -Original Message-
> From: Benjamin Mayrargue [mailto:benja...@vapolia.fr]
> Sent: Friday, May 31, 2013 9:59 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] ExePackage: rename exe before runnning it
>
> I need this feature because i'm launching an external installer (.exe) and
> i need to give it a serial number (user dependent, asked in the
> bootstrapper UI) as parameter, and the only way to give it this parameter
> is by renaming this exe file from INSTALLER.EXE to INSTALLER_SERIAL.exe Yes
> i know this is completely silly, but i don't have the hand on it.
>
> If i include it as a bootstrapper payload, is there a way to get it's
> pathname ? If yes, i'll run it manually (i don't need to track it).
> Or maybe by creating a msiPackage, or a custom action i can do it. I don't
> know the easiest way.
> Or last way, i create a windows exe which takes the correct parameters (as
> real parameters) and does the renaming / execution / and renaming back for
> wix.
>
> B.
>
>
>
> 2013/5/31 Rob Mensching 
>
> > No, and that won't work will with the way that Burn caches packages
> > and such. This scenario isn't supported today. Why do you need to do
> > such a thing?
> >
> >
> > On Fri, May 31, 2013 at 5:08 AM, Benjamin Mayrargue
> >  > >wrote:
> >
> > > Hi all again,
> > > i have a strange requirement.
> > >
> > > I need to rename the EXE file (set in ExePackage) before running it.
> > > The renaming involves a variable set and known only at runtime.
> > > Is this possible out of the box ?
> > >
> > > thks,
> > > B.
> > >
> > >
> > --
> > 
> > > Get 100% visibility into Java/.NET code with AppDynamics Lite It's a
> > > free troubleshooting tool designed for production Get down to
> > > code-level detail for bottlenecks, with <2% overhead.
> > > Download for free and get started troubleshooting in minutes.
> > > http://p.sf.net/sfu/appdyn_d2d_ap2
> > > ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> > >
> >
> > --
> >  Get 100% visibility into Java/.NET code with AppDynamics Lite
> > It's a free troubleshooting tool designed for production Get down to
> > code-level detail for bottlenecks, with <2% overhead.
> > Download for free and get started troubleshooting in minutes.
> > http://p.sf.net/sfu/appdyn_d2d_ap2
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free
> troubleshooting tool designed for production Get down to code-level detail
> for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2

Re: [WiX-users] ExePackage: rename exe before runnning it

[Hoover, Jacob]

Sounds like you need to talk to the person who thought of this "great" way of 
passing a parameter to their installer

That being said, you could create a stub exe, which takes the params and does 
this dance for you. I'd suggest making a copy in the temp folder for the 
install, and leaving what burn caches alone.  You'd change your ExePackage to 
reference your stub, and have the real installer exe as a Payload element.

You'd have to handle all of the commands for install, uninstall, repair, etc as 
params to your stub exe.

A lot of work, just because a 3rd party installer had a non-standard idea.

-Original Message-
From: Benjamin Mayrargue [mailto:benja...@vapolia.fr] 
Sent: Friday, May 31, 2013 9:59 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] ExePackage: rename exe before runnning it

I need this feature because i'm launching an external installer (.exe) and i 
need to give it a serial number (user dependent, asked in the bootstrapper UI) 
as parameter, and the only way to give it this parameter is by renaming this 
exe file from INSTALLER.EXE to INSTALLER_SERIAL.exe Yes i know this is 
completely silly, but i don't have the hand on it.

If i include it as a bootstrapper payload, is there a way to get it's pathname 
? If yes, i'll run it manually (i don't need to track it).
Or maybe by creating a msiPackage, or a custom action i can do it. I don't know 
the easiest way.
Or last way, i create a windows exe which takes the correct parameters (as real 
parameters) and does the renaming / execution / and renaming back for wix.

B.



2013/5/31 Rob Mensching 

> No, and that won't work will with the way that Burn caches packages 
> and such. This scenario isn't supported today. Why do you need to do 
> such a thing?
>
>
> On Fri, May 31, 2013 at 5:08 AM, Benjamin Mayrargue 
>  >wrote:
>
> > Hi all again,
> > i have a strange requirement.
> >
> > I need to rename the EXE file (set in ExePackage) before running it.
> > The renaming involves a variable set and known only at runtime.
> > Is this possible out of the box ?
> >
> > thks,
> > B.
> >
> >
> --
> 
> > Get 100% visibility into Java/.NET code with AppDynamics Lite It's a 
> > free troubleshooting tool designed for production Get down to 
> > code-level detail for bottlenecks, with <2% overhead.
> > Download for free and get started troubleshooting in minutes.
> > http://p.sf.net/sfu/appdyn_d2d_ap2
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
>
> --
>  Get 100% visibility into Java/.NET code with AppDynamics Lite 
> It's a free troubleshooting tool designed for production Get down to 
> code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free 
troubleshooting tool designed for production Get down to code-level detail for 
bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Windows 8 Resolution of variable written to registry

[Martin Johnson]

The following code snippet works on all OS with the exception of WIndows 8.  
e.g. on Windows 7 ExcelHelpPath32 has a correctly formatted path to the help 
file and TSDataDirectory has a correctly formatted path to the data Directory, 
On Windows 8 ExcelHelpPath32 is again correctly formatted whilst 
TSDataDirectory has the string [INSTALLDIRDATA].  I have removed some lines for 
clarity because I have 10 registry entries 5 work and 5 don't.

I have looked for any issues reported on Windows 8 installations but can't find 
anything, anyone got a clue what is going on?

  





additional lines removed


  






--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ExePackage: rename exe before runnning it

[Benjamin Mayrargue]

I need this feature because i'm launching an external installer (.exe) and
i need to give it a serial number (user dependent, asked in the
bootstrapper UI) as parameter, and the only way to give it this parameter
is by renaming this exe file from INSTALLER.EXE to INSTALLER_SERIAL.exe
Yes i know this is completely silly, but i don't have the hand on it.

If i include it as a bootstrapper payload, is there a way to get it's
pathname ? If yes, i'll run it manually (i don't need to track it).
Or maybe by creating a msiPackage, or a custom action i can do it. I don't
know the easiest way.
Or last way, i create a windows exe which takes the correct parameters (as
real parameters) and does the renaming / execution / and renaming back for
wix.

B.



2013/5/31 Rob Mensching 

> No, and that won't work will with the way that Burn caches packages and
> such. This scenario isn't supported today. Why do you need to do such a
> thing?
>
>
> On Fri, May 31, 2013 at 5:08 AM, Benjamin Mayrargue  >wrote:
>
> > Hi all again,
> > i have a strange requirement.
> >
> > I need to rename the EXE file (set in ExePackage) before running it.
> > The renaming involves a variable set and known only at runtime.
> > Is this possible out of the box ?
> >
> > thks,
> > B.
> >
> >
> --
> > Get 100% visibility into Java/.NET code with AppDynamics Lite
> > It's a free troubleshooting tool designed for production
> > Get down to code-level detail for bottlenecks, with <2% overhead.
> > Download for free and get started troubleshooting in minutes.
> > http://p.sf.net/sfu/appdyn_d2d_ap2
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ExePackage: rename exe before runnning it

[Rob Mensching]

No, and that won't work will with the way that Burn caches packages and
such. This scenario isn't supported today. Why do you need to do such a
thing?


On Fri, May 31, 2013 at 5:08 AM, Benjamin Mayrargue wrote:

> Hi all again,
> i have a strange requirement.
>
> I need to rename the EXE file (set in ExePackage) before running it.
> The renaming involves a variable set and known only at runtime.
> Is this possible out of the box ?
>
> thks,
> B.
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to use Burn

[Alain Forget]

Oh wow, I can't believe it's not butter working!

Yeah, as you've said, apparently one doesn't use burn.exe to use Burn...go 
figure. :-P In any case, I've got it working. For anyone who stumbles upon this 
thread with similar confusion, here's the process I use now to bundle the JRE 
with my MSI (N.B. if you don't do code signing, then omit the calls to 
signtool.exe and insignia):

candle.exe -ext WixUIExtension -ext WixUtilExtension MyMSIProductPackage.wxs
light.exe -ext WixUIExtension -ext WixUtilExtension MyMSIProductPackage.wixobj
"C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\signtool.exe" sign 
MyMSIProductPackage.msi
candle.exe -ext WixUtilExtension -ext WixBalExtension MyBundle.wxs 
JRE7PackageFragment.wxs
light.exe -ext WixUtilExtension -ext WixBalExtension MyBundle.wixobj 
JRE7PackageFragment.wixobj -o MyBundle.exe
insignia -ib MyBundle.exe -o engine.exe
"C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\signtool.exe" sign engine.exe
insignia -ab engine.exe MyBundle.exe -o MyBundle.exe
erase engine.exe
"C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\signtool.exe" sign 
MyBundle.exe

This seems to work like a charm. Now I just need to fine-tune (e.g. fix the UI, 
prevent the restore point, and try to pass a variable value to candle), but if 
I have problems, I'll start new threads.

Thanks so much for the help everyone!
Alain

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: May 30, 2013 21:22
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to use Burn

More simply: it's just a .wxs file. You compile and link the .wxs file like you 
do any other .wxs files. The burn.exe is in a "strange" place because it's just 
an implementation detail. Building your Bundle is just like building your MSI 
or your MSP or your MSM...


On Thu, May 30, 2013 at 4:00 PM, Hoover, Jacob
wrote:

> You use candle and light to compile the burn bundle as well.
>
> Sent from my iPhone
>
> On May 30, 2013, at 5:26 PM, "Alain Forget"  wrote:
>
> > Unfortunately, I'm not using Visual Studio, so I don't think that's 
> > an
> option.
> >
> > So what I'm currently trying to do is use candle/light to make
> MyMSIProductPackage.msi (which works great on its own), and then use 
> burn.exe to package it up with the Java Runtime Environment 7 exe 
> installer, to make sure Java is on the target machine before 
> MyMSIProductPackage.msi is unloaded.
> >
> > Am I doing things incorrectly?
> >
> > Alain
> >
> > -Original Message-
> > From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
> > Sent: May 30, 2013 18:21
> > To: afor...@cmu.edu; General discussion for Windows Installer XML
> toolset.
> > Subject: RE: [WiX-users] How to use Burn
> >
> > If you have Visual Studio, the Votive/integration that Wix provides
> hides most of this for you and it just works.  You don't use burn to 
> build the bundle, use candle/light to build it.
> >
> > From a rough point of view, the burn exe is the starting point for 
> > your
> bundle and some "magic" happens to cab up your BA and any embedded 
> payloads and then it's stuck into the exe at the end of the file.  The 
> exe knows to read this extra info, extract it, and execute the BA.
> >
> > -Original Message-
> > From: Alain Forget [mailto:afor...@cmu.edu]
> > Sent: Thursday, May 30, 2013 5:10 PM
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] How to use Burn
> >
> > It's time for me to step on the Burn noob school bus. :-)
> >
> > So I have the following file named MyBundle.wxs:
> >
> >  http://schemas.microsoft.com/wix/UtilExtension";>
> >
> > 
> > Id="WixStandardBootstrapperApplication.RtfLicense" />
> >
> >
> >
> > >Id="pkgMyMSI"
> >DisplayName="My MSI"
> >Cache="no"
> >Compressed="yes"
> >Permanent="yes"
> >SourceFile="MyMSIProductPackage.msi"
> >Visible="yes"
> >Vital="yes"
> >>
> >
> > 
> > 
> >
> > The file containing the Package "pkgJRE7" and 
> > MyMSIProductPackage.msi
> are in the same folder as MyBundle.wxs. When I run "burn.exe 
> MyBundle.wxs", nothing happens. No error, no new files, nothing. I 
> followed the examples here 
> (http://wix.sourceforge.net/manual-wix3/authoring_bundle_intro.htm)
> as closely as I could, but clearly I'm doin' it wrong.
> >
> > For example, how does burn know where to find pkgJRE7? The second
> example here (
> http://wix.sourceforge.net/manual-wix3/bundle_author_chain.htm) 
> doesn't have a reference to a file where MyPackage is located, 
> so...I'm guessing it somehow magically finds it?
> >
> >
> >
> > Another thing I find confusing is the burn.exe is located in a 
> > separate
> (sub)folder "x86" from all the other WiX tools. I'm not sure if that's 
> normal or not (i.e. it makes me wonder if it's the right program), but 
> it seems strange to me.
> >
> > Anyway, any help at all would be appreciated

Re: [WiX-users] Create Web app pool and Site on on Server 2008 R2 with IIS 7.5, WiX 3.7

[chennam]

Hi,

Can any one help me finding out where I am doing something wrong in creating
Site in IIS. CoreWebsServicesV3 is getting created twice and each one
pointing out to two different App pools.  one pointing to default app-pool
and another pointing to app-pool "CWSWebAppPool" which I have created. 

Thanks
Chatra



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Create-Web-app-pool-and-Site-on-on-Server-2008-R2-with-IIS-7-5-WiX-3-7-tp7586215p7586257.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] About DownloadURL

[Markus Wehrle]

Ok, I see.
If you want to have the ExePackage compressed into your bootstrapper.exe
(compressed="yes") you need to specify it using "Source" attribute. Cause it
will be compressed into your boostrapper during compile time, you must not
declare a DownloadUrl.
If you specifiy compressed="no" your ExePackage gets downloaded from the
DownloadUrl during the installation of your boostrapper.


> Benjamin Mayrargue  hat am 31. Mai 2013 um 14:03
> geschrieben:
> 
>  Sorry, this fails:
>  Compressed = "yes "
>   DownloadUrl = " $(var.UrlSauvegarde) "
> 
>  But this works perfectly:
>  Compressed = "no "
>   DownloadUrl = " $(var.UrlSauvegarde) "
> 
> 
> 
>  http://schemas.microsoft.com/wix/2006/wi>"
>   xmlns:util=""
>   xmlns:bal=""
> 
>   >
> 
>http://www.vapolia.fr/beta/produitVide1.exe>
>   ?>
> 
> UpgradeCode="BC841679-F636-4098-9EE7-3EAC3F055748"
>IconSourceFile='media\install.ico'
>AboutUrl='' Compressed='yes'
>DisableModify='yes' DisableRemove='yes'>
> 
>  
>
>   
>
> 
>
>  
>  Id="Sauvegarde"
>  InstallCommand=' /S -password="[PASSWORD64]" -user="[EMAIL]"'
>  PerMachine="yes"
>  Permanent="yes"
>  Vital="yes"
>  Cache="yes"
>  InstallSize="100"
>  Name="Sauvegarde.exe"
>  Compressed="no"
>  DownloadUrl="$(var.UrlSauvegarde)">
>   CertificatePublicKey="D2A6F974A08D42D7795C7AA5440E04E16DDCFD06"
> CertificateThumbprint="76DD0F11CF7E174ED20F160C3F991E6BF418A6FD"
> Description="ProduitVide" Hash="C792F08CF024CFB72F6634280D6E647F27C4ABB5"
> ProductName="ProduitVide" Size="81576" Version="1.0.0.0" />
>  
>  
>  
>  
>
>  
>
> 
>  
> 
> 
> 
> 
>  2013/5/31 Markus Wehrle mailto:mar...@laika42.com> >
>> >Hi Benjamin,
> > 
> >we do not have this issue and can successul download exe package in out
> > burn configuration.
> >Can you provide more details, e.g. the complete ExePackage definition and
> > the content of $(var.UrlSauvegarde)?
> > 
> > 
> >> Benjamin Mayrargue < benja...@vapolia.fr  >
> >> hat am 31. Mai 2013 um 10:33 geschrieben:
> >>
> >>
> >> Hi all,
> >> how are you today ?
> >> It's raining hard here in Paris.
> >>
> >> I have found a "bug" in 3.7 :)
> >>
> >> If an ExePackage has a DownloadUrl and Compressed is set to yes, light
> >> failed with error LGHT0103: The system cannot find the file '' with
> >> type ''.
> >>
> >> Compressed="no"
> >> DownloadUrl="$(var.UrlSauvegarde)"
> >>
> >> The error message should be more explicit :)
> >>
> >> B.
> >> 
> > --
> >> Get 100% visibility into Java/.NET code with AppDynamics Lite
> >> It's a free troubleshooting tool designed for production
> >> Get down to code-level detail for bottlenecks, with <2% overhead.
> >> Download for free and get started troubleshooting in minutes.
> >>
> >> ___
> >> WiX-users mailing list
> >> WiX-users@lists.sourceforge.net
> >> 
> >>
> >  > 

--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] ExePackage: rename exe before runnning it

[Benjamin Mayrargue]

Hi all again,
i have a strange requirement.

I need to rename the EXE file (set in ExePackage) before running it.
The renaming involves a variable set and known only at runtime.
Is this possible out of the box ?

thks,
B.
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] About DownloadURL

[Benjamin Mayrargue]

Sorry, this fails:
   Compressed="yes"
DownloadUrl="$(var.UrlSauvegarde)"

But this works perfectly:
   Compressed="no"
DownloadUrl="$(var.UrlSauvegarde)"


http://schemas.microsoft.com/wix/2006/wi";
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension";
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension";

 >

  http://www.vapolia.fr/beta/produitVide1.exe ?>

  

   
 










2013/5/31 Markus Wehrle 

> **
>  Hi Benjamin,
>
>  we do not have this issue and can successul download exe package in out
> burn configuration.
>  Can you provide more details, e.g. the complete ExePackage definition and
> the content of $(var.UrlSauvegarde)?
>
>
> > Benjamin Mayrargue  hat am 31. Mai 2013 um 10:33
> geschrieben:
> >
> >
> > Hi all,
> > how are you today ?
> > It's raining hard here in Paris.
> >
> > I have found a "bug" in 3.7 :)
> >
> > If an ExePackage has a DownloadUrl and Compressed is set to yes, light
> > failed with error LGHT0103: The system cannot find the file '' with type
> ''.
> >
> > Compressed="no"
> > DownloadUrl="$(var.UrlSauvegarde)"
> >
> > The error message should be more explicit :)
> >
> > B.
> >
> --
>
> > Get 100% visibility into Java/.NET code with AppDynamics Lite
> > It's a free troubleshooting tool designed for production
> > Get down to code-level detail for bottlenecks, with <2% overhead.
> > Download for free and get started troubleshooting in minutes.
> > http://p.sf.net/sfu/appdyn_d2d_ap2
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] About DownloadURL

[Markus Wehrle]

Hi Benjamin,

we do not have this issue and can successul download exe package in out burn
configuration.
Can you provide more details, e.g. the complete ExePackage definition and the
content of $(var.UrlSauvegarde)?


> Benjamin Mayrargue  hat am 31. Mai 2013 um 10:33
> geschrieben:
>
>
> Hi all,
> how are you today ?
> It's raining hard here in Paris.
>
> I have found a "bug" in 3.7 :)
>
> If an ExePackage has a DownloadUrl and Compressed is set to yes, light
> failed with error LGHT0103: The system cannot find the file '' with type ''.
>
> Compressed="no"
> DownloadUrl="$(var.UrlSauvegarde)"
>
> The error message should be more explicit :)
>
> B.
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Why is install not elevated? Access Denied to Program Files (deferred CA)

[Tom -]

Good afternoon,
 
This is driving me crazy. I can on my Windows 7 run this installation I've 
created and the custom action successfully writes a database backup-file (a 
.bak-file that it has as an embedded resource in its assembly) to the 
Temp-directory provided by Path.GetTempPath(). On my computer, it restores this 
database successfully, creating the MDF/LDF database-files in the Program 
Files\Manufacturer\Product directory.
 
However, a different user gets access denied to Program Files when the restore 
is attempted. Him being in another country makes this complicated to 
troubleshoot, so I'm wondering if I'm missing some detail in my code here. I am 
running perMachine, and elevated, and set the custom actions to deferred. The 
directory-path sent to the custom action gets sent correctly. The backup-file 
is written correctly to disk by the custom-action. (Please ignore the part of 
the code that writes a .bak-file to disk, it's a remnant.) But the failure 
comes when doing the final step of the "installTpdb"-customaction, which is a 
restore:
 

http://schemas.microsoft.com/wix/2006/wi"; 
xmlns:netfx="http://schemas.microsoft.com/wix/NetFxExtension";>
  























  



  

  

  
  

  
  

  




  


  
  NOT Installed
  NOT Installed
  NOT 
Installed
  (NOT 
UPGRADINGPRODUCTCODE) AND (REMOVE="ALL")





  

 
>From the logfile and custom action, it always throws this exception:
 
Exception thrown by custom action:
System.Reflection.TargetInvocationException: Exception has been thrown by the 
target of an invocation. ---> System.UnauthorizedAccessException: Access to the 
path 'C:\Program Files (x86)\MyCompanyName\Database WiXTest' is denied.
 
I think I see the problem in the logfile from the client's machine, and it is:
 
MSI (c) (5C:80) [10:10:58:316]: Machine policy value 'DisablePatch' is 0
MSI (c) (5C:80) [10:10:58:317]: Machine policy value 'AllowLockdownPatch' is 0
MSI (c) (5C:80) [10:10:58:317]: Machine policy value 'DisableMsi' is 0
MSI (c) (5C:80) [10:10:58:317]: Machine policy value 'AlwaysInstallElevated' is 0
MSI (c) (5C:80) [10:10:58:317]: User policy value 'AlwaysInstallElevated' is 0
MSI (c) (5C:80) [10:10:58:317]: Running product '{myproductcoderemoved}' with 
user privileges: It's not assigned.

On my machine, it says:
 
MSI (c) (14:40) [10:58:13:252]: Product installation will be elevated because 
user is admin and product is being installed per-machine.
MSI (c) (14:40) [10:58:13:252]: Running product '{myproductcoderemoved}' with 
elevated privileges: Product is assigned.
 
The question is, what to do about it? Or any way to work around it? Any which 
way to write to Program Files would be awesome. It really is the most 
convenient for me to be able to write to Program Files during the installation. 
The database backup-file contains data, and there will be cases where I need to 
copy a database from a SQL 2005 server to SQL 2008 server on the same machine, 
where backup/restore is the most convenient mechanism. I could achieve all 
things by generating scripts, and generate some scripts for transfering data, 
but I would prefer to do it this way because the database-work utilizes tried 
and tested code that exists in the application associated with the database 
(the application is installed separately.)
 
Thank you in advance for any and every suggestion! :-)
  
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] About DownloadURL

[Benjamin Mayrargue]

Hi all,
how are you today ?
It's raining hard here in Paris.

I have found a "bug" in 3.7 :)

If an ExePackage has a DownloadUrl and Compressed is set to yes, light
failed with error LGHT0103: The system cannot find the file '' with type ''.

Compressed="no"
DownloadUrl="$(var.UrlSauvegarde)"

The error message should be more explicit :)

B.
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix dev and regular dev best practices

[Albert van Peppen]

We use a lot of (VS) Project Property Sheets. For WiX we have defined several 
property sheets for this. Our solution gives us the possibility to change the 
location where WixTools are etc. This way we can easily switch between WiX 
versions as well (assuming the schema, on what we use, hasn't been broken)

Just my 2 ct ;)

Best regards,

Albert van Peppen

-Oorspronkelijk bericht-
Van: John Ludlow [mailto:john.ludlow...@gmail.com] 
Verzonden: 30 May 2013 17:06
Aan: General discussion for Windows Installer XML toolset.
Onderwerp: Re: [WiX-users] Wix dev and regular dev best practices

@Mark:

Yep, that's what we've gone with, but we had issues getting the right set of 
properties to set up the paths properly because there's a number of cascading 
properties. Also, we had issues in that we have to do this with every .wixproj. 
(I guess we might create a customized .wixproj which has those changes already)

Thanks


On 30 May 2013 15:28, Freedman, Mark P.  wrote:

> I've recently added WiX to my continuous integration server, Team City.
> They key is to not have to install stuff on the build machines. WiX 
> includes the install binaries that can be put right in your source tree.
> However the binaries do not include the files necessary for Custom 
> Actions (CAs), so I had to include some extra files that come with the 
> standard WiX developer install.
>
> http://wix.codeplex.com/releases/view/99514
>
> Then, update your .wixproj projects to point to the relative path to 
> your wix binaries. See the Wix tags in .
>
>   
> Debug
> x86
> 3.7
> z
> 2.0
> My  Installer
> Package
> ..\..\InstallTools\wix\3.7.1224.0\
> $(WixToolPath)Wix.targets
> wixtasks.dll
>   
>
>
> If you're doing bootstrappers prerequisites with the 
> GenerateBootstrapper command, you can do something similar in your 
> project's bootstrapper to redirect them to a  relative path so that 
> the build machine doesn't need to have Visual Studio installed, or 
> whatever puts them in the default Microsoft SDK package.
>
>  ApplicationName="My App " BootstrapperItems="@(BootstrapperFile)"
> ComponentsLocation="Relative" CopyComponents="True"
> OutputPath="$(OutputPath)" Path="..\..\Bootstrapper" />
>
> Mark Freedman
>
>
> -Original Message-
> From: John Ludlow [mailto:john.ludlow...@gmail.com]
> Sent: Thursday, May 30, 2013 5:53 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Wix dev and regular dev best practices
>
> We're looking at simply making WiX part of the toolkit you need to 
> build our solutions.  We've tried this with some smaller projects and 
> it's worked really well. Developers can follow up on their own 
> impacts, and they can tell when they've broken the install. This 
> increases build quality and frees up install developers from the "add a file, 
> remove a file"
> monkey-work we seem to spend 80% of our time doing.
>
> Some of the developers grumbled a bit, but it's also been taken 
> positively by others, and everyone gets a bit more respect for their 
> poor, abused install developers. :)
>
> In fact, the main issues are related to integrating it into our build 
> system (which is more down to the fact that we don't want to install 
> stuff onto our build system - we want the build to be able to xcopy 
> install whatever it needs).
>
>
>
>
>
> On 29 May 2013 18:46,  wrote:
>
> > I don't know if our approach will work well long term since we are 
> > still developing all of this, but we decided we'd build front end 
> > utilities for developers to use with presets implicitly written out 
> > to wxs for them (like Manufacturer and expected directories to 
> > install to, etc.). This way in principle we could also have 
> > developers (or in your case, a build server) drop off their files 
> > and an installer build person / process can then pick them up with the 
> > front end to WIX.
> >
> >
> >
> > Keith Douglas
> > Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
> > Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A
> > 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 
> > Facsimile | Télécopieur 613-951-1966 Government of Canada | 
> > Gouvernement du Canada
> >
> >
> > -Original Message-
> > From: Drake, David [mailto:david.dr...@wizards.com]
> > Sent: May-29-13 1:41 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: [WiX-users] Wix dev and regular dev best practices
> >
> > I am attempting to bring an extra layer of automation to my area of 
> > concern and have chosen to start packaging up each of our services 
> > into .msi files for easier deployment and configuration.  Part of 
> > getting started is figuring out the best way to implement WIX 
> > installers into our build system without causing impact on the 
> > developers.  My initial thought was to add wix projects to the 
> > various solutions we have in source