[WiX-users] Problem installing merge modules on server 2008 R2

[Rob]

I am having a problem in that I cannot get WIX to install these files


  
  
  






The wix project builds and installs but as these are not installed, the my
service will not run. If I look at the installer log it looks like it is
trying to create directories in windows\winsxs, but when I look for these
folders they have not been created. If I look in Process monitor there is
no mention of trying to create these directories/files, only trying to read
them and failing.


Am I doing something wrong in my wix code? Seems to work fine on Windows 7
etc

Thanks

Rob
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Problem installing merge modules on server 2008 R2

[Rob]

Great. That was my problem. Thanks for your help. Much appreciated

Rob


On 23 January 2013 11:48, Rob Hamflett  wrote:

> Starting with Vista the WinSxS runtime assemblies aren't committed until
> InstallFinalize.  This meant my service couldn't be started as part of
> the StartServices action.  I had to write a commit custom action to
> start the service for me.  It's possible that this is the issue you're
> running into, and it just happens to work on Windows 7 because the
> runtime you need is already there.  Don't start the service during the
> installation, and see if you can start it from the Services panel
> afterwards.
>
> Rob
>
> On 21/01/2013 12:57, Rob wrote:
> > I am having a problem in that I cannot get WIX to install these files
> >
> >  > SourceFile="$(env.MS_MERGE_MODULES)\Microsoft_VC90_CRT_x86.msm"
> DiskId="1"
> > />
> > > SourceFile="$(env.MS_MERGE_MODULES)\Microsoft_VC90_MFC_x86.msm"
> DiskId="1"
> > />
> > >
> SourceFile="$(env.MS_MERGE_MODULES)\policy_9_0_Microsoft_VC90_CRT_x86.msm"
> > DiskId="1" />
> > >
> SourceFile="$(env.MS_MERGE_MODULES)\policy_9_0_Microsoft_VC90_MFC_x86.msm"
> > DiskId="1" />
> >
> > 
> >  
> >  
> >  
> >
> > The wix project builds and installs but as these are not installed, the
> my
> > service will not run. If I look at the installer log it looks like it is
> > trying to create directories in windows\winsxs, but when I look for these
> > folders they have not been created. If I look in Process monitor there is
> > no mention of trying to create these directories/files, only trying to
> read
> > them and failing.
> >
> >
> > Am I doing something wrong in my wix code? Seems to work fine on Windows
> 7
> > etc
> >
> > Thanks
> >
> > Rob
> >
> --
> > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> > MVPs and experts. SALE $99.99 this month only -- learn more at:
> > http://p.sf.net/sfu/learnmore_122412
> >
>
>
>
>
> --
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnnow-d2d
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 

Rob Freer

Software Developer



*Cambridge Imaging Systems*

DDI: +44 (0)1954 262005 | Mobile: +44 (0)7508303880

The Grange | 44 High Street | Willingham | Cambridge | CB24 5ES

www.cambridgeimaging.co.uk | rob.fr...@cambridgeimaging.co.uk
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Handling Possible ExitCodes in ExePackage

[Rob Mensching]

I think a log file would be necessary:
https://support.firegiant.com/entries/24024218-Create-a-log-file-


On Wed, Jun 26, 2013 at 11:23 AM, Steve Merckel  wrote:

> I have an ExePackage defined,
> which can output a few different exit codes.  What I would like to have
> happen, is to prompt for restart at the end of the bootstrapper's chain
> if a specific exit code was returned.
>
>  DisplayName="MyCustomDotNetExe"
> InstallCommand="true"
> Description="DescriptionGoesHere">
>   Behavior="error" />
> 
> 
>   />
> 
>
> Including the ExitCode nodes in the above package builds a Setup.EXE file
> that does not run.
> My goal is to have the bootstrapper consider that the ExePackage was run
> successfully if "0" or "1" is returned, but also schedule a reboot if
> "1" was returned.
>
> Thoughts?
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Is it possible to have a bundle without a UI?

[Rob Mensching]

It is possible however you'd need to write a custom BA. The wixstdba
(provided with the WiX toolset) is designed to create a "single
installation experience" not "bunch of independent installs popping up".


On Thu, Jun 27, 2013 at 2:48 AM, Vinoth M  wrote:

> I think this is not possible with WIX Bootstrapper. Please find my answer
> in stack overflow for the same requirement.
>
> http://stackoverflow.com/a/17043234/1124244
>
> -Original Message-
> From: Shay Friedman [mailto:shay.fried...@gmail.com]
> Sent: Thursday, June 27, 2013 2:42 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Is it possible to have a bundle without a UI?
>
> Hi,
>
> I've created an installer using WIX and it works fine. Now I want to add a
> prerequisite installer that installs .NET before the actual installer jumps
> in.
> The thing is that I don't want UI for this bootstrapper... I want something
> like the following flow:
> - Check if .NET is installed
> - if not, run .NET installer.
> - Run my MSI (with its UI and everything)
>
> How can I (if it's even possible) achieve that using the WIX toolset?
>
> Many thanks,
> Shay.
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> ScannedByWebsenseForEurofins
>
>
> This message has been scanned for malware by SurfControl plc.
> www.surfcontrol.com
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [SPAM] Re: Bootstrapper multiple MSI's don't rollback to a working installed state

[Rob Mensching]

Not today. Multi-MSI Transaction API was buggy (that's why you don't seen
major Microsoft products using it). We should eventually add it as an
opt-in feature to Burn at some point so that if your MSIs can handle it
Burn will support it.


On Thu, Jun 27, 2013 at 10:01 AM, Phil Wilson  wrote:

> This is the problem that a single transaction over multiple MSI installs
> can
> solve. At the risk of stating the obvious, the transaction (a.msi+b.msi) is
> not committed until b.msi is successful. The failure of b.msi will roll
> back
> b.msi AND a.msi, and the rollback of a.msi will reinstall the older version
> of a.msi. A rollback of a major upgrade will reinstall the previous product
> because RemoveExistingProducts will be rolled back if it is part of the
> transaction (between InstallInitialize and InstallFinalize). As I say, I
> don't know if Burn supports multiple MSI single transaction installs.
>
> Phil
>
> -Original Message-
> From: Simon Fogliato [mailto:sfogli...@deltacontrols.com]
> Sent: Wednesday, June 26, 2013 3:01 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Bootstrapper multiple MSI's don't rollback to a
> working installed state
>
> You are correct this is how it is currently working in WiX 3.7 and this is
> my problem. The MSI that fails (b.msi) does rollback correctly, my issue is
> that the installed files of a.msi are lost until I manually repair the
> previous bootstrapper version from add/remove programs.
>
> A RollbackBoundary only makes the problem worse because then I have 2
> bootstrapper installed listed applications that are not completely
> installed
> over 1.
>
> To my knowledge the bootstrapper just doesn't do a complete multiple MSI
> rollback.
>
> -Original Message-
> From: Nick Ramirez [mailto:nickra...@hotmail.com]
> Sent: Wednesday, June 26, 2013 12:42 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Bootstrapper multiple MSI's don't rollback to a
> working installed state
>
> The MajorUpgrade schedule is important for the MSI that failed. If an MSI
> will be rolled back, having the original MSI reinstalled is dependent on
> the
> MajorUpgrade element. On the other hand, the first MSI, which installed
> fully, will not roll back. At best, when the Chain fails, it will probably
> just be uninstalled. I am thinking that right after it was installed, the
> old A.msi was removed from the Package Cache (replaced by the upgraded
> A.msi). So, I'm not sure that Burn will support reinstalling the older,
> replaced package.
>
> I'm guessing, this is the problem:
>
> - MSI A installs sucessfully
> - MSI B fails midway through, triggers rollback of itself and the chain
> - MSI B is rolled back and its older version is reinstalled (if
> MajorUpgrade
> is set up to do this)
> - MSI A is uninstalled <-- and that's where it ends
>
> Someone with more insight regarding how major upgrades and rollbacks work
> could probably say if this is how it works. But I think it has to do with
> not keeping the old package in the cache and not having a mechanism to
> resurrect it.
>
> You could add Rollback Boundaries to not uninstall A.msi, but that may not
> be the behavior you want.
>
>
>
> --
> View this message in context:
>
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bootstrapper-m
>
> ultiple-MSI-s-don-t-rollback-to-a-working-installed-state-tp7586867p7586885.
> html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> 
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> 
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Is it possible to have a bundle without a UI?

[Rob Mensching]

That's reasonable too. 

I've considered creating such a thing before but it's not particularly
interesting problem for me so it's not a place where I'd choose to invest
my volunteer time.


On Thu, Jun 27, 2013 at 10:25 AM, Alan Fors  wrote:

> That's a reasonable statement Rob. It would be nice, however, if there was
> a simple prerequisite BA packaged with WiX. I'd like to do the same as Shay
> is requesting, without needing to write a custom BA, or re-crafting the MSI
> UI in the wixstdba.
>
> Alan
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Thursday, June 27, 2013 1:11 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Is it possible to have a bundle without a UI?
>
> It is possible however you'd need to write a custom BA. The wixstdba
> (provided with the WiX toolset) is designed to create a "single
> installation experience" not "bunch of independent installs popping up".
>
>
> On Thu, Jun 27, 2013 at 2:48 AM, Vinoth M  wrote:
>
> > I think this is not possible with WIX Bootstrapper. Please find my
> > answer in stack overflow for the same requirement.
> >
> > http://stackoverflow.com/a/17043234/1124244
> >
> > -Original Message-
> > From: Shay Friedman [mailto:shay.fried...@gmail.com]
> > Sent: Thursday, June 27, 2013 2:42 PM
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] Is it possible to have a bundle without a UI?
> >
> > Hi,
> >
> > I've created an installer using WIX and it works fine. Now I want to
> > add a prerequisite installer that installs .NET before the actual
> > installer jumps in.
> > The thing is that I don't want UI for this bootstrapper... I want
> > something like the following flow:
> > - Check if .NET is installed
> > - if not, run .NET installer.
> > - Run my MSI (with its UI and everything)
> >
> > How can I (if it's even possible) achieve that using the WIX toolset?
> >
> > Many thanks,
> > Shay.
> >
> > --
> >  This SF.net email is sponsored by Windows:
> >
> > Build for Windows Store.
> >
> > http://p.sf.net/sfu/windows-dev2dev
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> > ScannedByWebsenseForEurofins
> >
> >
> > This message has been scanned for malware by SurfControl plc.
> > www.surfcontrol.com
> >
> >
> > --
> >  This SF.net email is sponsored by Windows:
> >
> > Build for Windows Store.
> >
> > http://p.sf.net/sfu/windows-dev2dev
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>   CONFIDENTIAL INFORMATION: This transmission, as well as any attached
> file or images transmitted contemporaneously, contain(s) confidential
> information that are subject to certain and specific privileges, or
> otherwise protected against unauthorized use, all of which are hereby
> reserved by PlateSmart. The information contained in this transmission, as
> well as any file or images transmitted contemporaneously, is transmitted in
> this form based on a reasonable expectation of privacy, consistent with
> U.S. law. Any disclosure, distribution, copying, or use of the information
> contained in this transmission by any person, regardless of address or
> routing, is strictly prohibited. If you have received this transmission in
> error, please advise the sender immediately, and delete any materials.
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [SPAM] Re: [SPAM] Re: Bootstrapper multiple MSI's don't rollback to a working installed state

[Rob Mensching]

Jacob, exactly right and that's just the beginning. We saw strange behavior
in early tests based on whether you installed a 32-bit or 64-bit MSI
package before the other (I forget the order). There are all kinds of
subtle issues that start coming out.

I have an old motto: If neither Office nor Visual Studio use a particular
feature in the Windows Installer, assume the feature does not work.


On Thu, Jun 27, 2013 at 10:27 AM, Hoover, Jacob
wrote:

> This would get ugly if you had mixed bundles with other installers (Exe
> packages from 3rd parties).
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Thursday, June 27, 2013 12:17 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] [SPAM] Re: Bootstrapper multiple MSI's don't rollback
> to a working installed state
>
> Not today. Multi-MSI Transaction API was buggy (that's why you don't seen
> major Microsoft products using it). We should eventually add it as an
> opt-in feature to Burn at some point so that if your MSIs can handle it
> Burn will support it.
>
>
> On Thu, Jun 27, 2013 at 10:01 AM, Phil Wilson 
> wrote:
>
> > This is the problem that a single transaction over multiple MSI
> > installs can solve. At the risk of stating the obvious, the
> > transaction (a.msi+b.msi) is not committed until b.msi is successful.
> > The failure of b.msi will roll back b.msi AND a.msi, and the rollback
> > of a.msi will reinstall the older version of a.msi. A rollback of a
> > major upgrade will reinstall the previous product because
> > RemoveExistingProducts will be rolled back if it is part of the
> > transaction (between InstallInitialize and InstallFinalize). As I say,
> > I don't know if Burn supports multiple MSI single transaction installs.
> >
> > Phil
> >
> > -Original Message-
> > From: Simon Fogliato [mailto:sfogli...@deltacontrols.com]
> > Sent: Wednesday, June 26, 2013 3:01 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Bootstrapper multiple MSI's don't rollback to
> > a working installed state
> >
> > You are correct this is how it is currently working in WiX 3.7 and
> > this is my problem. The MSI that fails (b.msi) does rollback
> > correctly, my issue is that the installed files of a.msi are lost
> > until I manually repair the previous bootstrapper version from
> add/remove programs.
> >
> > A RollbackBoundary only makes the problem worse because then I have 2
> > bootstrapper installed listed applications that are not completely
> > installed over 1.
> >
> > To my knowledge the bootstrapper just doesn't do a complete multiple
> > MSI rollback.
> >
> > -Original Message-
> > From: Nick Ramirez [mailto:nickra...@hotmail.com]
> > Sent: Wednesday, June 26, 2013 12:42 PM
> > To: wix-users@lists.sourceforge.net
> > Subject: Re: [WiX-users] Bootstrapper multiple MSI's don't rollback to
> > a working installed state
> >
> > The MajorUpgrade schedule is important for the MSI that failed. If an
> > MSI will be rolled back, having the original MSI reinstalled is
> > dependent on the MajorUpgrade element. On the other hand, the first
> > MSI, which installed fully, will not roll back. At best, when the
> > Chain fails, it will probably just be uninstalled. I am thinking that
> > right after it was installed, the old A.msi was removed from the
> > Package Cache (replaced by the upgraded A.msi). So, I'm not sure that
> > Burn will support reinstalling the older, replaced package.
> >
> > I'm guessing, this is the problem:
> >
> > - MSI A installs sucessfully
> > - MSI B fails midway through, triggers rollback of itself and the
> > chain
> > - MSI B is rolled back and its older version is reinstalled (if
> > MajorUpgrade is set up to do this)
> > - MSI A is uninstalled <-- and that's where it ends
> >
> > Someone with more insight regarding how major upgrades and rollbacks
> > work could probably say if this is how it works. But I think it has to
> > do with not keeping the old package in the cache and not having a
> > mechanism to resurrect it.
> >
> > You could add Rollback Boundaries to not uninstall A.msi, but that may
> > not be the behavior you want.
> >
> >
> >
> > --
> > View this message in context:
> >
> > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bootstra
> > pper-m

[WiX-users] [SPAM] Re: Bootstrapper multiple MSI’s don’ t rollback to a working installed state

[Rob Mensching]

Bug http://sourceforge.net/p/wix/bugs/2766/ captures some of the relevant
issues. This is a very hard problem to solve correctly in Burn (think about
all the scenarios for a while and you'll see how deep the rabbit hole
goes). Multi-MSI Tx is a reasonable way out if it worked reliably (our
tests showed it was a very screwy API) and was everywhere (only MSI4.5+).

In the end, we decided on a solution where repair would fix things. Other
choices lead you into options where not even repair can get you fixed.



On Wed, Jun 26, 2013 at 3:00 PM, Simon Fogliato  wrote:

> You are correct this is how it is currently working in WiX 3.7 and this is
> my problem. The MSI that fails (b.msi) does rollback correctly, my issue is
> that the installed files of a.msi are lost until I manually repair the
> previous bootstrapper version from add/remove programs.
>
> A RollbackBoundary only makes the problem worse because then I have 2
> bootstrapper installed listed applications that are not completely
> installed over 1.
>
> To my knowledge the bootstrapper just doesn’t do a complete multiple MSI
> rollback.
>
> -Original Message-
> From: Nick Ramirez [mailto:nickra...@hotmail.com]
> Sent: Wednesday, June 26, 2013 12:42 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Bootstrapper multiple MSI’s don’t rollback to a
> working installed state
>
> The MajorUpgrade schedule is important for the MSI that failed. If an MSI
> will be rolled back, having the original MSI reinstalled is dependent on
> the MajorUpgrade element. On the other hand, the first MSI, which installed
> fully, will not roll back. At best, when the Chain fails, it will probably
> just be uninstalled. I am thinking that right after it was installed, the
> old A.msi was removed from the Package Cache (replaced by the upgraded
> A.msi). So, I'm not sure that Burn will support reinstalling the older,
> replaced package.
>
> I'm guessing, this is the problem:
>
> - MSI A installs sucessfully
> - MSI B fails midway through, triggers rollback of itself and the chain
> - MSI B is rolled back and its older version is reinstalled (if
> MajorUpgrade is set up to do this)
> - MSI A is uninstalled <-- and that's where it ends
>
> Someone with more insight regarding how major upgrades and rollbacks work
> could probably say if this is how it works. But I think it has to do with
> not keeping the old package in the cache and not having a mechanism to
> resurrect it.
>
> You could add Rollback Boundaries to not uninstall A.msi, but that may not
> be the behavior you want.
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bootstrapper-multiple-MSI-s-don-t-rollback-to-a-working-installed-state-tp7586867p7586885.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WIX 3.7 and Windows 2000

[Rob Mensching]

MSIs created by WiX toolset will run fine (as long as you target Windows
Installer that supports Win2k).

However, any WiX code that gets carried with your MSI (like custom actions
or Burn) require WinXP SP2+.


On Thu, Jun 27, 2013 at 12:36 PM, Andrew Jones
wrote:

> Am I right in assuming that an installer created with WIX 3.7 will not run
> on Windows 2000? Did V3.6 create installers that will run on Windows 2000?
> Can you have both 3.6 and 3.7 installed at the same time?
>
> Andrew
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] http://wixtoolset.org infrastructure updates next few days

[Rob Mensching]

Over the next couple days, we're going to be doing some upgrades to the 
http://wixtoolset.org infrastructure. As a result the website will probably be 
up and down and all around. Apologies in advance for any issues this might 
cause you.
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX-users Digest, Vol 85, Issue 138

[Rob Mensching]

Burn is only used when you create a Bundle. Any version of the WiX toolset
can target any version of the Windows Installer so I recommend using the
latest version, v3.7.


On Thu, Jun 27, 2013 at 1:23 PM, Andrew Jones wrote:

> > MSIs created by WiX toolset will run fine (as long as you target Windows
> Installer that supports Win2k).
>
> > However, any WiX code that gets carried with your MSI (like custom
> actions or Burn) require WinXP SP2+.
>
> I assume it must be Burn as I don't have any custom actions. To get
> something that will install on Windows 2000 do I need to go back to 3.5 or
> 3.6?
>
> Andrew
>
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [SPAM] Re: Bootstrapper multiple MSI’s don’ t rollback to a working installed state

[Rob Mensching]

Wow, look, I'm self consistent system (at least in email). Not bad for a
human, eh? 


On Thu, Jun 27, 2013 at 9:46 AM, Nick Ramirez  wrote:

> I think you're right. This other thread seems to agree:
>
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Installl-upgrade-several-MSIs-in-one-single-transaction-td7495903.html
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bootstrapper-multiple-MSI-s-don-t-rollback-to-a-working-installed-state-tp7586867p7586915.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] wixtoolset.org 3.7 download Error 404

[Rob Mensching]

I sent email end of last week noting big infrastructure changes to website.
We're still working through those changes. It should be all good again
by end of day Monday.


On Sun, Jun 30, 2013 at 6:11 PM, Phill Hogland  wrote:

> FYI - Tonight when I click on the button "Wix v3.7 released! Download>>" at
> wixtoolset.org I get Error 404m file not found.  I tried several times
> tonight.  However under the release announcement post lower on that same
> page is a link to the Wix 3.7 which works.  Maybe there are some changes
> being made to the web site because the button at the top of the page worked
> a few days ago from my work PC.
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/wixtoolset-org-3-7-download-Error-404-tp7587021.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Upgrade uninstall restart issue

[Rob Mensching]

I don't know what in Burn would lock existing files. Burn is very
self-contained and only uses files it carries with it, although a custom BA
can do anything. If you haven't already, I'd recommend using Process
Monitor to see if what locks your files when they are trying to be removed.
I'd be very surprised if it was anything in the Burn process.

The order you are seeing in Burn is expected. There are some details here:
https://support.firegiant.com/entries/24024208-Bundle-chain-execution-order-

Note: Burn will not install or uninstall packages that are not explicitly
listed in the Chain today. However, a package in your chain may upgrade an
existing package on the machine during install.

Note2: Very screwy that a package would be detected per-user when it is
really per-machine. That would be something to investigate further.



On Sun, Jun 30, 2013 at 7:43 PM, Alain Forget  wrote:

> I know about those, but how do I use them to prevent Burn from locking the
> existing files before it runs the installer package to MajorUpgrade?
>
> -Original Message-
> From: Phill Hogland [mailto:phogl...@rimage.com]
> Sent: June 30, 2013 20:54
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Upgrade uninstall restart issue
>
> Maybe this blog would be helpful:
>
> http://code.dblock.org/msi-property-patterns-upgrading-firstinstall-and-maintenance
>
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrade-uninstall-restart-issue-tp7586315p7587020.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn: Related Package ID

[Rob Mensching]

You're doing great! 

It would be a reasonable thing to bug... but it's fixed in a more recent
build so no need to do that now. 


On Tue, Jul 2, 2013 at 7:40 AM, Adam Roper wrote:

> So that's two responses saying that this is a known thing.  Do I add that
> as a bug?  Sorry, I'm new to this list, not sure of the correct etiquette
> at this point
>
>
> -Original Message-
> From: Wesley Manning [mailto:wmann...@dynagen.ca]
> Sent: 02 July 2013 14:40
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Burn: Related Package ID
>
> Happens to me as well.  Burn is not smart enough to get the name.
>
> Wes
>
> -Original Message-
> From: Adam Roper [mailto:adam.ro...@guidance.eu.com]
> Sent: July-02-13 9:46 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Burn: Related Package ID
>
> Hi,
>
> I have a Burn bundle that incorporates 9 other MSI packages and everything
> works remarkably well, other than one thing.
>
> During installation the names of the included packages is displayed on the
> installation screen as they are installed in turn.  However I have noticed
> that when I install a new version of the compiled Burn package over the top
> of an existing package, then following what I think should be the final
> package there is an extra notification to say that package {GUID} is being
> installed, where the GUID is a real GUID of course.  I believe that this
> 'anonymous' may actually be the encompassing package, but the bundle has an
> ID so I can't think why it would be displaying this.
>
> I've searched through the registry for this GUID but it doesn't exist.
>  This is completely reproducible, at least with my bundle.  Any ideas?
>
> Cheers
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn: Related Package ID

[Rob Mensching]

Burn doesn't do things that the BA can do easily to avoid bloating the
engine (and the BA interface) with lots of stuff to maintain. In WiX v3.8
the wixstdba looks up the display name for the related bundle and displays
that.


On Tue, Jul 2, 2013 at 6:40 AM, Wesley Manning  wrote:

> Happens to me as well.  Burn is not smart enough to get the name.
>
> Wes
>
> -Original Message-
> From: Adam Roper [mailto:adam.ro...@guidance.eu.com]
> Sent: July-02-13 9:46 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Burn: Related Package ID
>
> Hi,
>
> I have a Burn bundle that incorporates 9 other MSI packages and everything
> works remarkably well, other than one thing.
>
> During installation the names of the included packages is displayed on the
> installation screen as they are installed in turn.  However I have noticed
> that when I install a new version of the compiled Burn package over the top
> of an existing package, then following what I think should be the final
> package there is an extra notification to say that package {GUID} is being
> installed, where the GUID is a real GUID of course.  I believe that this
> 'anonymous' may actually be the encompassing package, but the bundle has an
> ID so I can't think why it would be displaying this.
>
> I've searched through the registry for this GUID but it doesn't exist.
>  This is completely reproducible, at least with my bundle.  Any ideas?
>
> Cheers
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Download packages only if custom action returns some value

[Rob Mensching]

WixBA is written in managed code.


On Tue, Jul 2, 2013 at 1:53 AM, DavidH  wrote:

> I'm aware the CA won't stop anyone who really wants to circumvent it, but
> hopefully it'll at least reduce the number of people who download packages
> they shouldn't.
>
> Thanks for the pointers about WixBA - I'd looked but hadn't found one
> written in C# before. I'll look into modifying it for our purposes.
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Download-packages-only-if-custom-action-returns-some-value-tp7587032p7587058.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Removing bundle after installing MSI's

[Rob Mensching]

I don't understand the reasoning here "I''m unwilling at this point to let
the bundle take over the handling of the MSI". What is the real difference
between having the Bundle registered as the ARP entry vs. the MSI
registered as the ARP entry?

Random note: Burn will clean up the package cache during uninstall, one
more reason (that just came to mind) it should be the ARP entry.

To address your question, "what do we do about MSI's that require user
input?" - you interact with the user in the Bundle and pass the results to
the MsiPackage via the MsiProperty element. This does require moving your
user interaction out of the  MSI into the BA so it takes dev work.

As noted in the blog entry, The goal for Burn is to provide is a unified
user experience for installation. You'll fight Burn if you truly desire a
disjointed installation experience.

Now, I have yet to have anyone describe a scenario where their ultimate
goal is to provide users a installation experience where multiple things
pop up such that users must  interact with the install multiple times as it
progresses. I've certainly never seen such an experience test well with
users. User's want to click "Install" then see "Success!" with as little
time and interaction as possible.

That said, sometimes all you have time to develop is a disjoint user
experience. If so, you can get that if you treat the Bundle as the "main
MSI" and hide the "main MSI" ARP entry. Alternatively you can use a
different bootstrapper. There are plenty of bootstrappers out there that
provide disjoint user experiences for installation. Burn exists because
nothing provided the seamless user experience user's wanted.

This comes up enough that I feel like I'm missing something.



On Fri, Jul 5, 2013 at 6:15 AM, Miller, Bill (QuickWire) <
bmil...@quickwire.com> wrote:

> I was faced with the same dilemma. I wanted to simply use the bundle to
> pave the way for my main MSI.
> As it is I've set the Permanent & Visible attribute of all the Package
> elements in the bundle to "yes".
> Thus when the bundle is finished it has an entry in the ARP but
> uninstalling it essentially does nothing.
>
> However, we both don't want this. Here is an entry from Rob Mensching's
> blog that sums up what he thinks about bundles.
>
> http://robmensching.com/blog/posts/2012/6/25/b-is-for-bundle-and-thats-good-enough-for-me
>
> It makes sense, but what do we do about MSI's that require user input?
> My MSI requires an alternate install location so I need to use its
> interface. I'm unwilling at this point to let the bundle take over the
> handling of the MSI - by setting Permanent & Visible to 'no' (as the issue
> I'm now having as seen in my previous msg)
> I suppose if I did then there would simply be one entry in the ARP and
> life would be better (like a beer commercial).
>
> So I'm on the fence right now about bundles myself.
>
> Bill
>
>
> -Original Message-
> From: James McConville [mailto:james.mcconvi...@orbussoftware.com]
> Sent: Friday, July 5, 2013 5:39 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Removing bundle after installing MSI's
>
> Hello all,
>
> Need to find out if this is possible or if I've completely missed the
> point of Bundles.
>
> Is it possible to remove all traces of the bundle after installation, not
> just hide it.
>
> Essentially I want to use the bundle purely as a delivery method for the
> app and its dependent apps (which I want to leave alone if I remove the
> msi).
>
> Is it possible to do this or should I be looking at another solution?
>
> Thanks for your help!
> James.
>
>
>
>
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Removing bundle after installing MSI's

[Rob Mensching]

I want to re-iterate what Blair said here.

The Burn engine does a whole lot of stuff to get your packages on the
machine correctly and get them off correctly. Caching the packages is a
very important part of that. If you don't register the Bundle as the ARP
entry there isn't anything to clean up the cache.

Now, you could mark the packages Cache='no' but then you're no better off
than using one of those other
fire-and-forget/disjoint-user-experience bootstrappers that won't help you
improve your install success rate. Burn wasn't designed to be that.

Note: With Burn and a custom BA that shows the MSI UI, you can get the
experience Sean Hall wants.  However, I'd argue you want some UI while the
packages are downloaded/uncompressed, so you need some UI in the BA. There
is a thread about this and how I noted it was a reasonable feature request
but I wasn't interested in volunteering my time to write it. 

Finally, there are some powerful mechanisms you can use when the Bundle is
registered as well when it comes to related bundles. I appreciate that if
you many not be using any of the additional functionality, yet. However, I
hope you can see there are many reasons for the current design and how they
try to point you in the direction of a very robust installation experience.

That's what we're trying to do any way (delta bugs ).



On Sat, Jul 6, 2013 at 3:59 AM, Blair Murri  wrote:

> Without something like the bundle, the cached MSI is without its CABs
> ("Thank You Windows Installer" for stripping the embedded cabs and for not
> storing the external ones either) and thus Repair is broken unless the MSI
> is placed in some protected area by its bootstrapper (which most don't do).
>
> The bundle provided by burn supplies a cache external to Windows Installer
> for the MSI with its CABs (which will only be cleaned if the bundle's ARP
> is used instead of the MSIs, as pointed out by Rob).
>
> Burn promotes usability on many levels (not withstanding the occasional
> error) .
>
> Also, for most teams after picking baseline source code for their BA the
> UI is easier to maintain for a bundle than it is for MSIs (another plus
> once you've taken the initial cost).
>
> Blair
>
> > From: rhal...@hotmail.com
> > To: wix-users@lists.sourceforge.net
> > Date: Fri, 5 Jul 2013 19:04:16 -0500
> > Subject: Re: [WiX-users] Removing bundle after installing MSI's
> >
> > I think what you're missing is that you're assuming every package in the
> chain has a user interface.  My typical installer has my application MSI,
> and at least one prerequisite (i.e. .NET).  I want the bootstrapper to
> silently install the prerequisites, and only show UI for the MSI.  Once the
> bootstrapper has done its thing, there's no reason for it anymore.  All
> modify/repair/uninstall logic is in the MSI, which should have been cached.
> >
> > Where is the logic to install the bundle?  Could there be a
> PrerequisiteBA that performs this functionality, or would you have to
> modify the engine to do this?
> >
> > Sean
> >
> > > From: r...@robmensching.com
> > > Date: Fri, 5 Jul 2013 14:04:28 -0700
> > > To: wix-users@lists.sourceforge.net
> > > Subject: Re: [WiX-users] Removing bundle after installing MSI's
> > >
> > > I don't understand the reasoning here "I''m unwilling at this point to
> let
> > > the bundle take over the handling of the MSI". What is the real
> difference
> > > between having the Bundle registered as the ARP entry vs. the MSI
> > > registered as the ARP entry?
> > >
> > > Random note: Burn will clean up the package cache during uninstall, one
> > > more reason (that just came to mind) it should be the ARP entry.
> > >
> > > To address your question, "what do we do about MSI's that require user
> > > input?" - you interact with the user in the Bundle and pass the
> results to
> > > the MsiPackage via the MsiProperty element. This does require moving
> your
> > > user interaction out of the  MSI into the BA so it takes dev work.
> > >
> > > As noted in the blog entry, The goal for Burn is to provide is a
> unified
> > > user experience for installation. You'll fight Burn if you truly
> desire a
> > > disjointed installation experience.
> > >
> > > Now, I have yet to have anyone describe a scenario where their ultimate
> > > goal is to provide users a installation experience where multiple
> things
> > > pop up such that users must  interact with the install multiple times
> as it
> > > prog

Re: [WiX-users] Authenticode signatures

[Rob Mensching]

I think the Shell caches aggressively. Try restarting and see if the Shell
still tells you it's signed.


On Mon, Jul 8, 2013 at 4:13 AM, David Watson  wrote:

> It should come up as unsigned in the UAC prompt, if you have that disabled
> you won't see anything. You can usually still install it.
>
> -Original Message-
> From: Ivo Beltchev [mailto:i...@ibeltchev.com]
> Sent: 07 July 2013 23:34
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Authenticode signatures
>
> Hi
>
>
>
> I have a digital certificate and I signed my MSI with it. When I view the
> properties of the file in Explorer it shows the certificate correctly. So
> far
> so good.
>
>
>
> Then I modified the MSI file in a binary editor (changed one byte). Now
> when
> I run the signtool I get an error that the verification failed. So far so
> good.
>
>
>
> But when I view the file properties I still see the certificate. I was able
> to run the MSI and install it. I was expecting Explorer to detect the file
> as
> corrupted and for the MSI to fail to install.
>
>
>
> What am I missing? Is there an extra step during the WiX pipeline that I
> need
> to do, or were my expectations wrong that a file modification will be
> caught
> by Windows?
>
>
>
> Thanks
>
> Ivo
>
>
>
>
> -
> -
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> SDL PLC confidential, all rights reserved.
> If you are not the intended recipient of this mail SDL requests and
> requires that you delete it without acting upon or copying any of its
> contents, and we further request that you advise us.
> SDL PLC is a public limited company registered in England and Wales.
>  Registered number: 02675207.
> Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6
> 7DY, UK.
>
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Resolve Light 1056 Warning

[Rob Mensching]

The Merge Modules have a bug in them. Have the produce fix them... or
ignore the warning.


On Wed, Jul 10, 2013 at 9:21 AM, Kathy Morey  wrote:

> I am creating a WiX installer for an application that requires some
> Microsoft merge modules.
>
> I'm getting several warnings like:
>
> warning LGHT1056: The Directory table contains a row with primary key(s)
> 'SystemFolder' which cannot be merged from the merge module
> 'C:\_blah\blah\COMCAT.MSM'.  This is likely due to collision of rows with
> the same primary key(s) (but other different values in other columns)
> between the database and the merge module.
>
> I looked at the merge module and my MSI with Orca and found this
> difference in the DefaultDir column of the Directory table:
>
> MM DefaultDir - .:System32
> My DefaultDir - System32
>
> How do I author my project so that I get the ".:" designation in the
> DefaultDir column?
>
> Kathy Morey
> Synergy Software Engineer
> Profitstars, a Jack Henry Company
> 700 Tower Drive, Suite 600
> Troy MI 48098
> Office: 248.879.0316 ext. 454809
> Email: kmo...@profitstars.com
> 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.
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Resolve Light 1056 Warning

[Rob Mensching]

Steve, basically, yes:
http://robmensching.com/blog/posts/2008/10/10/what-are-.wixlibs-and-why-would-you-use-them


On Thu, Jul 11, 2013 at 5:48 AM, Steven Ogilvie wrote:

> Sigh,
>
> I am confused... When I was using InstallShield (for many years) I was
> told to always use Merge Modules, easier for upgrading, and easier for
> grouping "features".
>
> I have a Server MSI and a Services MSI which is bundled in burn so the
> bootstrapper can take care of the pre reqs etc...
>
> In my Services MSI I have 6 Merge Modules, where each Service is a Merge
> Module, I also have several WixLibs of "common files" and share those
> WixLibs within the Merge Modules. The Merge Modules where used mainly for
> Upgrading...
>
> Are the majority of you saying it makes more sense to get rid of the Merge
> Modules and just use the WixLibs?
>
> Steve
>
> -Original Message-
> From: John Cooper [mailto:jocoo...@jackhenry.com]
> Sent: July-11-13 8:34 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Resolve Light 1056 Warning
>
> Yes, I really hate merge modules.  Wixlibs are much better.  Always have
> issues with merge modules I haven't authored.
>
> --
> 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: Kathy Morey
> Sent: Wednesday, July 10, 2013 4:22 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Resolve Light 1056 Warning
>
> FYI
>
> It turns out that, although John's suggestion did work, different
> Microsoft merge modules have different values for some of the standard
> folders, and so I will be following Rob's suggestion and just ignoring
> those warnings.
>
> Thanks.
>
> -Original Message-
> From: Kathy Morey
> Sent: Wednesday, July 10, 2013 5:08 PM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: RE: Resolve Light 1056 Warning
>
> Thanks, John.
>
> That did it for me.
>
>
> -Original Message-
> From: John Cooper
> Sent: Wednesday, July 10, 2013 12:50 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Resolve Light 1056 Warning
>
> I was able to get the ".:System32" by using
>
> 
> 
>  Source="$(var.SolutionDir).nuget\NuGet.exe" />
> 
> 
>
> --
> 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: Kathy Morey
> Sent: Wednesday, July 10, 2013 11:22 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] Resolve Light 1056 Warning
>
> I am creating a WiX installer for an application that requires some
> Microsoft merge modules.
>
> I'm getting several warnings like:
>
> warning LGHT1056: The Directory table contains a row with primary key(s)
> 'SystemFolder' which cannot be merged from the merge module
> 'C:\_blah\blah\COMCAT.MSM'.  This is likely due to collision of rows with
> the same primary key(s) (but other different values in other columns)
> between the database and the merge module.
>
> I looked at the merge module and my MSI with Orca and found this
> difference in the DefaultDir column of the Directory table:
>
> MM DefaultDir - .:System32
> My DefaultDir - System32
>
> How do I author my project so that I get the ".:" designation in the
> DefaultDir column?
>
> Kathy Morey
> Synergy Software Engineer
> Profitstars, a Jack Henry Company
> 700 Tower Drive, Suite 600
> Troy MI 48098
> Office: 248.879.0316 ext. 454809
> Email: kmo...@profitstars.com
> 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.
>
> --
> See everything from the browser to the database with AppDynamics Get
> end-to-end visibility with application monitoring from AppDynamics Isolate
> bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> 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 

Re: [WiX-users] Burn : SQL Express 2008 R2 certificate problem

[Rob Mensching]

Since you're using a RemotePayload element, the
SuppressSignatureVerification isn't going to do anything. You will want to
remove the certificate information from the RemotePayload and populate the
Hash instead.


On Wed, Jul 10, 2013 at 11:58 PM, Tobias S  wrote:

> At first glance I'd say to SuppressSignatureVerification="yes" but that's
> already done. What about keeping the SQL install locally without
> downloading and therefore modify the  definition accordingly?
> (Remove everything beginning with . Or what about re-sign
> the SQL setup.exe with a correct SQL certificate?
>
>
> 2013/7/10 Loïc DELAMBRE 
>
> > Hello,
> >
> > I'm trying to chain many prerequisites to my product : .NET 4.0 or 4.5,
> > IIS and SQL Server Express which has some prerequisites too : .NET 3.5,
> > Windows Installer 4.5, Powershell. It needs to work under Windows Server
> > 2003 SP2, 2008 SP2/2008R2 RTM and 2012 RTM.
> >
> > I'm near the goal, but I have a problem with SQL Express setup files :
> > there are signed with a bad/expired Authenticode certificate and I have
> an
> > error during the bootstrapper :
> > [0A58:0A90][2013-07-10T18:03:54]i338: Acquiring package:
> SQL2008R2Exprx86,
> > payload: SQL2008R2Exprx86, copy from: C:\Documents and
> > Settings\Administrateur\Bureau\Debug\redist\sql2008r2\SQLEXPR_x86_ENU.exe
> > [0A70:0A84][2013-07-10T18:03:57]e000: Error 0x800b0101: Failed
> > authenticode verification of payload: C:\Documents and Settings\All
> > Users\Application Data\Package Cache\.unverified\SQL2008R2Exprx86
> > [0A70:0A84][2013-07-10T18:03:57]e000: Error 0x800b0101: Failed to verify
> > signature of payload: SQL2008R2Exprx86
> > [0A70:0A84][2013-07-10T18:03:57]e310: Failed to verify payload:
> > SQL2008R2Exprx86 at path: C:\Documents and Settings\All Users\Application
> > Data\Package Cache\.unverified\SQL2008R2Exprx86, error: 0x800b0101.
> > Deleting file.
> > [0A70:0A84][2013-07-10T18:03:57]e000: Error 0x800b0101: Failed to cache
> > payload: SQL2008R2Exprx86
> > [0A58:0A90][2013-07-10T18:03:57]e314: Failed to cache payload:
> > SQL2008R2Exprx86 from working path:
> >
> C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{f3bd1d56-bde5-4ff8-8b96-d0e4f9748f99}\SQL2008R2Exprx86,
> > error: 0x800b0101.
> > [0A58:0A90][2013-07-10T18:03:57]e349: Application requested retry of
> > payload: SQL2008R2Exprx86, encountered error: 0x800b0101. Retrying...
> > [0A58:0A90][2013-07-10T18:04:00]i338: Acquiring package:
> SQL2008R2Exprx86,
> > payload: SQL2008R2Exprx86, copy from: C:\Documents and
> > Settings\Administrateur\Bureau\Debug\redist\sql2008r2\SQLEXPR_x86_ENU.exe
> > [0A70:0A84][2013-07-10T18:04:04]e000: Error 0x800b0101: Failed
> > authenticode verification of payload: C:\Documents and Settings\All
> > Users\Application Data\Package Cache\.unverified\SQL2008R2Exprx86
> > [0A70:0A84][2013-07-10T18:04:04]e000: Error 0x800b0101: Failed to verify
> > signature of payload: SQL2008R2Exprx86
> > [0A70:0A84][2013-07-10T18:04:04]e310: Failed to verify payload:
> > SQL2008R2Exprx86 at path: C:\Documents and Settings\All Users\Application
> > Data\Package Cache\.unverified\SQL2008R2Exprx86, error: 0x800b0101.
> > Deleting file.
> > [0A70:0A84][2013-07-10T18:04:04]e000: Error 0x800b0101: Failed to cache
> > payload: SQL2008R2Exprx86
> > [0A58:0A90][2013-07-10T18:04:04]e314: Failed to cache payload:
> > SQL2008R2Exprx86 from working path:
> >
> C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{f3bd1d56-bde5-4ff8-8b96-d0e4f9748f99}\SQL2008R2Exprx86,
> > error: 0x800b0101.
> > [0A58:0A90][2013-07-10T18:04:04]e349: Application requested retry of
> > payload: SQL2008R2Exprx86, encountered error: 0x800b0101. Retrying...
> > [0A58:0A90][2013-07-10T18:04:07]i338: Acquiring package:
> SQL2008R2Exprx86,
> > payload: SQL2008R2Exprx86, copy from: C:\Documents and
> > Settings\Administrateur\Bureau\Debug\redist\sql2008r2\SQLEXPR_x86_ENU.exe
> > [0A70:0A84][2013-07-10T18:04:10]e000: Error 0x800b0101: Failed
> > authenticode verification of payload: C:\Documents and Settings\All
> > Users\Application Data\Package Cache\.unverified\SQL2008R2Exprx86
> > [0A70:0A84][2013-07-10T18:04:10]e000: Error 0x800b0101: Failed to verify
> > signature of payload: SQL2008R2Exprx86
> > [0A70:0A84][2013-07-10T18:04:10]e310: Failed to verify payload:
> > SQL2008R2Exprx86 at path: C:\Documents and Settings\All Users\Application
> > Data\Package Cache\.unverified\SQL2008R2Exprx86, error: 0x800b0101.
> > Deleting file.
> > [0A70:0A84][2013-07-10T18:04:10]e000: Error 0x800b0101: Failed to cache
> > payload: SQL2008R2Exprx86
> > [0A58:0A90][2013-07-10T18:04:10]e314: Failed to cache payload:
> > SQL2008R2Exprx86 from working path:
> >
> C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{f3bd1d56-bde5-4ff8-8b96-d0e4f9748f99}\SQL2008R2Exprx86,
> > error: 0x800b0101.
> >
> > I tried to put SuppressSignatureVerification attribute on the ExePackage
> :
> >  > Id="SQL2008R2Exprx86"
> > Name="redist\sql2008r2\SQLEXPR_x86_ENU.exe"
> > InstallCondition="NOT VersionNT

Re: [WiX-users] Resolve Light 1056 Warning

[Rob Mensching]

Wixlibs are missing the redirect directory feature of Merge Modules so
converting wouldn't be that straight forward in this case. In general,
.wixlibs work better but there are specific cases where using specific
features of a Merge Module means you'll want to stick with a Merge Module
(and keep all the other downsides).


On Thu, Jul 11, 2013 at 6:46 AM, Steven Ogilvie wrote:

> Each merge Module contains 3 file elements (one or two dll's and a .config
> file) and a bunch of Custom Actions
> I have about 10 wixlibs that are shared between the Merge Modules (dll's
> that are shared between the merge modules but are installed to different
> directories)
> Each merge module is a different service... I have 5 merge modules.
>
> So are you saying to "convert" each merge module to a wixlib? Can I still
> share the wixlibs within a wixlib?
>
> Here is a typical Merge Module (I have excluded the custom actions, about
> 10 of them)
>  SourceFile="$(var.InstallerCAMM)"/>
>
> 
>Name="EnterpriseSettingsService">
>
> 
>   
>   
>Directory="WixLibRedirectFolder" On="uninstall" />
>   
> 
>   
> EventMessageFile="[NETFRAMEWORK40FULLINSTALLROOTDIR]EventLogMessages.dll"
> Log=" Labs"/>
>   
> 
> 
>   
> EventMessageFile="[NETFRAMEWORK40FULLINSTALLROOTDIR64]EventLogMessages.dll"
> Log=" Labs"/>
>   
> 
> 
>Source="$(var.tssSourcePath)\.Enterprise.Settings.Host\ company>.Enterprise.Settings.Host.dll" />
>   
> 
>Name=".Enterprise.Settings.Host.dll.config"
> Source="$(var.tssSourcePath)\.Enterprise.Settings.Host\ company>.Enterprise.Settings.Host.dll.config" />
>   
>
>     
>   
>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> 
> 
>  SuppressModularization="yes"/>
>  SuppressModularization="yes"/>
>  SuppressModularization="yes"/>
>  SuppressModularization="yes"/>
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: July-11-13 9:27 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Resolve Light 1056 Warning
>
> Steve, basically, yes:
>
> http://robmensching.com/blog/posts/2008/10/10/what-are-.wixlibs-and-why-would-you-use-them
>
>
> On Thu, Jul 11, 2013 at 5:48 AM, Steven Ogilvie  >wrote:
>
> > Sigh,
> >
> > I am confused... When I was using InstallShield (for many years) I was
> > told to always use Merge Modules, easier for upgrading, and easier for
> > grouping "features".
> >
> > I have a Server MSI and a Services MSI which is bundled in burn so the
> > bootstrapper can take care of the pre reqs etc...
> >
> > In my Services MSI I have 6 Merge Modules, where each Service is a
> > Merge Module, I also have several WixLibs of "common files" and share
> > those WixLibs within the Merge Modules. The Merge Modules where used
> > mainly for Upgrading...
> >
> > Are the majority of you saying it makes more sense to get rid of the
> > Merge Modules and just use the WixLibs?
> >
> > Steve
> >
> > -Original Message-
> > From: John Cooper [mailto:jocoo...@jackhenry.com]
> > Sent: July-11-13 8:34 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Resolve Light 1056 Warning
> >
> > Yes, I really hate merge modules.  Wixlibs are much better.  Always
> > have issues with merge modules I haven't authored.
> >
> > --
> > 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: Kathy Morey
> > Sent: Wednesday, July 10, 2013 4:22 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Resolve Light 1056 Warning
> >
> > FYI
> >
> > It turns out that, although John's suggestion did work, different
> > Microsoft merge modules have different values for some of the standard
> > folders, and so I will be follo

[WiX-users] [SPAM] Re: Bundle with wrong size in Add/Remove entry

[Rob Mensching]

The ARP size is the installed size, not the size of the Bundle. 415MB seems
with in range if the 120MB was all compressed stuff.


On Fri, Jul 12, 2013 at 8:16 AM, Niander Neves de Assis <
niander.ne...@gmail.com> wrote:

> Ok, But my bootstrapper (the .exe file generated) has the size of 120MB,
> and in the entry at Add/Remove programs the size of the bootstrapper is
> 415MB. I want to fix this.
>
>
> 2013/7/12 Alain Forget 
>
> > I wondered the same thing, but I think it makes sense as it is, since the
> > all bundles for all installed programs are stored in C:/Windows/Installer
> > for when modifications, repairs, and uninstalls are needed.
> >
> > Alain
> >
> > -Original Message-
> > From: nianderneves [mailto:niander.ne...@gmail.com]
> > Sent: July 12, 2013 09:30
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] Bundle with wrong size in Add/Remove entry
> >
> > Hello,
> >
> > My bundle generated with the Burn engine is showing a wrong size in
> > Add/Remove entry. Maybe it's not wrong, the size is just the sum of all
> > packages in the chain. Anyway, I want that my bundle only shows the size
> of
> > my application, not the size of the prerequisites like .Net Framework
> > client and other packages in the chain.
> > Can anyone helps me?
> >
> > Thx, Niander.
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bundle-with-wrong-size-in-Add-Remove-entry-tp7587326.html
> > Sent from the wix-users mailing list archive at Nabble.com.
> >
> >
> >
> --
> > See everything from the browser to the database with AppDynamics Get
> > end-to-end visibility with application monitoring from AppDynamics
> Isolate
> > bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> >
> >
> --
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix burn 64-bit

[Rob Mensching]

That looks like an extremely long path as well. Have you exceeded the 260
chars the NETFX supports?


On Thu, Jul 18, 2013 at 8:20 AM, Hoover, Jacob
wrote:

> Can you humor me and try building the project via the command line when
> using the "VS 2012 x86 Native Tools Command Prompt"?
>
> -Original Message-
> From: José Marques [mailto:jose.marq...@waveform.pt]
> Sent: Thursday, July 18, 2013 9:57 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Wix burn 64-bit
>
> The only reason I consider not using burn it's because it's failing me at
> the moment, but I would be very happy to use it.
> I have installed Wix (not using binaries), and I'm building my bundle
> through Visual Studio Ultimate 2012.
> I've found very little information about the error I'm getting (see my
> first post), and that's why I'm struggling with burn.
>
> Thank you very much for all the replies.
>
> On Thu, Jul 18, 2013 at 3:44 PM, Hoover, Jacob
> wrote:
>
> > Why wouldn't you want burn if you need a bootstrapper?  Did you
> > install Wix, or are you using the zip of binaries?  How are you
> > building your bundle (command line or via Visual Studio)?  What
> > version of MSBuild or VS are you using?
> >
> > -Original Message-
> > From: José Marques [mailto:jose.marq...@waveform.pt]
> > Sent: Thursday, July 18, 2013 9:38 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Wix burn 64-bit
> >
> > Thank you for your reply Daniel.
> > But if burn should run as a 32-bit application, where am I going wrong
> > here?
> > A link to a no-burn bootstrapper tutorial would be appreciated :)
> >
> > José Marques
> >
> > On Thu, Jul 18, 2013 at 3:21 PM, Daniel Madill  > >wrote:
> >
> > > Hi Jose,
> > >
> > > I have not used burn because I have my own bootstrapper for now, but
> > > I believe burn runs as a 32-bit application even on 64-bit Windows.
> > > You can still chain 64-bit MSIs though, as far as I know.
> > >
> > > Daniel Madill
> > > www.quanser.com
> > >
> > > -Original Message-
> > > From: José Marques [mailto:jose.marq...@waveform.pt]
> > > Sent: July-18-13 9:57 AM
> > > To: wix-users@lists.sourceforge.net
> > > Subject: [WiX-users] Wix burn 64-bit
> > >
> > > Hello all,
> > > I'm pretty new at Wix, and was doing my first ever Installer.
> > > As I have some prerequisites (like UltiDev WebServer and MSMQ).
> > > I intended to do a Bootstraper, but as soon as i tried to compile it
> > > (code shown below) I get the following error:
> > >
> > > Error 2 Could not find a part of the path
> > >
> > >
> >
> '(...)Local\assembly\dl3\4WGE307K.364\MTB4TPQV.BGA\81446d46\007377db_d3e1cd01\X86\burn.exe'.
> > > light.exe 0 1 Bootstrapper
> > >
> > > After some searching I found (at least i think i found) the reason:
> > > burn is not available for 64 bit (
> > >
> > > http://sourceforge.net/mailarchive/forum.php?thread_name=CAHdHTVdH4o
> > > 9D
> > > _ObXbtVgx5gBMRKkdgfsVMKqd1fPA%2BqJrjUq0A%40mail.gmail.com&forum_name
> > > =w
> > > ix-users
> > > ).
> > > I'm running Windows 7 Ultimate 64 bit and Wix 3.7.
> > >
> > > Does this means I have to make a bootstrap without burn? If so, how
> > > can I do that?
> > >
> > > Thank you for your time!
> > >
> > > Code:
> > >
> > >   > > xmlns="http://schemas.microsoft.com/wix/2006/wi";
> > >  xmlns:util="http://schemas.microsoft.com/wix/UtilExtension";>
> > >> > UpgradeCode="47017954-51f0-42d3-a8ad-9743de168695">
> > >  > > Id="WixStandardBootstrapperApplication.RtfLicense" />
> > >
> > > 
> > >> > Id="Setup"
> > > SourceFile="Dependencies\UltiDev.Webserver.msi" />
> > > 
> > >   
> > > 
> > >
> > > 
> > > --
> > >  See everything from the browser to the database with
> > > AppDynamics Get end-to-end visibility with application monitoring
> > > from AppDynamics Isolate bottlenecks and diagnose root cause in
> seconds.
> > > Start your free trial of AppDynamics Pro today!
> > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg
> > > .c lktrk ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> > >
> > > 
> > > --
> > >  See everything from the browser to the database with
> > > AppDynamics Get end-to-end visibility with application monitoring
> > > from AppDynamics Isolate bottlenecks and diagnose root cause in
> seconds.
> > > Start your free trial of AppDynamics Pro today!
> > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg
> > > .c lktrk ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> >
> > 

Re: [WiX-users] Wix burn 64-bit

[Rob Mensching]

Error 2 Could not find a part of the path
'(...)Local\assembly\dl3\4WGE307K.364\MTB4TPQV.BGA\81446d46\007377db_d3e1cd01\X86\burn.exe'.
light.exe 0 1 Bootstrapper
I assume the "(...)" in your error message means there are more characters
there. If you count them.. how many are there?

Also, you didn't GAC the wix.dll did you (path looks a little like it might
be GAC'd)? That would definitely cause issues as well...


On Thu, Jul 18, 2013 at 9:26 AM, José Marques wrote:

> How can I check that?
>
> On Thu, Jul 18, 2013 at 5:17 PM, Rob Mensching 
> wrote:
>
> > That looks like an extremely long path as well. Have you exceeded the 260
> > chars the NETFX supports?
> >
> >
> > On Thu, Jul 18, 2013 at 8:20 AM, Hoover, Jacob
> > wrote:
> >
> > > Can you humor me and try building the project via the command line when
> > > using the "VS 2012 x86 Native Tools Command Prompt"?
> > >
> > > -Original Message-
> > > From: José Marques [mailto:jose.marq...@waveform.pt]
> > > Sent: Thursday, July 18, 2013 9:57 AM
> > > To: General discussion for Windows Installer XML toolset.
> > > Subject: Re: [WiX-users] Wix burn 64-bit
> > >
> > > The only reason I consider not using burn it's because it's failing me
> at
> > > the moment, but I would be very happy to use it.
> > > I have installed Wix (not using binaries), and I'm building my bundle
> > > through Visual Studio Ultimate 2012.
> > > I've found very little information about the error I'm getting (see my
> > > first post), and that's why I'm struggling with burn.
> > >
> > > Thank you very much for all the replies.
> > >
> > > On Thu, Jul 18, 2013 at 3:44 PM, Hoover, Jacob
> > > wrote:
> > >
> > > > Why wouldn't you want burn if you need a bootstrapper?  Did you
> > > > install Wix, or are you using the zip of binaries?  How are you
> > > > building your bundle (command line or via Visual Studio)?  What
> > > > version of MSBuild or VS are you using?
> > > >
> > > > -Original Message-
> > > > From: José Marques [mailto:jose.marq...@waveform.pt]
> > > > Sent: Thursday, July 18, 2013 9:38 AM
> > > > To: General discussion for Windows Installer XML toolset.
> > > > Subject: Re: [WiX-users] Wix burn 64-bit
> > > >
> > > > Thank you for your reply Daniel.
> > > > But if burn should run as a 32-bit application, where am I going
> wrong
> > > > here?
> > > > A link to a no-burn bootstrapper tutorial would be appreciated :)
> > > >
> > > > José Marques
> > > >
> > > > On Thu, Jul 18, 2013 at 3:21 PM, Daniel Madill <
> dan.mad...@quanser.com
> > > > >wrote:
> > > >
> > > > > Hi Jose,
> > > > >
> > > > > I have not used burn because I have my own bootstrapper for now,
> but
> > > > > I believe burn runs as a 32-bit application even on 64-bit Windows.
> > > > > You can still chain 64-bit MSIs though, as far as I know.
> > > > >
> > > > > Daniel Madill
> > > > > www.quanser.com
> > > > >
> > > > > -Original Message-
> > > > > From: José Marques [mailto:jose.marq...@waveform.pt]
> > > > > Sent: July-18-13 9:57 AM
> > > > > To: wix-users@lists.sourceforge.net
> > > > > Subject: [WiX-users] Wix burn 64-bit
> > > > >
> > > > > Hello all,
> > > > > I'm pretty new at Wix, and was doing my first ever Installer.
> > > > > As I have some prerequisites (like UltiDev WebServer and MSMQ).
> > > > > I intended to do a Bootstraper, but as soon as i tried to compile
> it
> > > > > (code shown below) I get the following error:
> > > > >
> > > > > Error 2 Could not find a part of the path
> > > > >
> > > > >
> > > >
> > >
> >
> '(...)Local\assembly\dl3\4WGE307K.364\MTB4TPQV.BGA\81446d46\007377db_d3e1cd01\X86\burn.exe'.
> > > > > light.exe 0 1 Bootstrapper
> > > > >
> > > > > After some searching I found (at least i think i found) the reason:
> > > > > burn is not available for 64 bit (
> > > > >
> > > > >
> http://sourceforge.net/mailarchive/forum.php?thread_name=CAHdHTVdH4o
> > > > >

Re: [WiX-users] Convert from MSI to EXE [P]

[Rob Mensching]

Sure. Use Burn. The MSI will just be inside the executable. See the
"Bundle" element.


On Thu, Jul 18, 2013 at 11:30 AM, Steven Ogilvie
wrote:

> Classification: Public
> No I don't believe so...
>
> -Original Message-
> From: Mamidi, Balasubrahmanyam [mailto:balu.mam...@flightsafety.com]
> Sent: July-18-13 2:20 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Convert from MSI to EXE
>
> Thanks for reply steve. not clear what you're saying..
>
> Let me reframe what I want..
> When I compile my project I want .exe to be generated. I do not want .msi
> file to be generated. Is it possible using WIX?
>
>
> -Original Message-
> From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
> Sent: Thursday, July 18, 2013 1:00 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Convert from MSI to EXE [P]
>
> Classification: Public
> Hi Balu,
>
> You can use burn (bootstrapper) (which is an EXE) to launch your MSI's
>
> Steve
>
> -Original Message-
> From: Mamidi, Balasubrahmanyam [mailto:balu.mam...@flightsafety.com]
> Sent: July-18-13 1:52 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] Convert from MSI to EXE
>
> Hi, currently we are creating our product to MSI file (using wix ), now
> client is asking convert all products to EXE's.
>
> How much effort to do this and give me some idea please? Is something
> change output file extension to from *.msi to *.exe
>
> Thanks,
> Balu
>
>
>
>
> --
> See everything from the browser to the database with AppDynamics Get
> end-to-end visibility with application monitoring from AppDynamics Isolate
> bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> This message has been marked as Public by Steven Ogilvie on July-18-13
> 1:59:37 PM.
>
> The above classification labels were added to the message by TITUS Message
> Classification. For more information visit www.titus.com.
>
>
>
>
>
>
> --
> See everything from the browser to the database with AppDynamics Get
> end-to-end visibility with application monitoring from AppDynamics Isolate
> bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> See everything from the browser to the database with AppDynamics Get
> end-to-end visibility with application monitoring from AppDynamics Isolate
> bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> This message has been marked as Public by Steven Ogilvie on July-18-13
> 2:30:23 PM.
>
> The above classification labels were added to the message by TITUS Message
> Classification. For more information visit www.titus.com.
>
>
>
>
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [SPAM] Re: Wix 3.7 Burn error '0x80004005: Failed to extract all files from container.'

[Rob Mensching]

dark.exe can extract the files. This error has been intermittent. If you
have a consistent repro, it would be awesome if you could use Process
Monitor to capture everything going on through the failure. Then put the
.pml file and the corresponding burn.log somewhere and I'd like to take a
look.


On Mon, Jul 22, 2013 at 2:55 PM, TimM  wrote:

> Okay tried a few thing suggested in to following web page, but still no
> go...
> Still same 0x80004005 error on extraction of files.
>
> Is there a command line that we can call to manually extract all files
> within the Burn bootstrapper .exe so that we can verify that the files are
> actually in the .exe file?
>
> Thanks.
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-3-7-Burn-error-0x80004005-Failed-to-extract-all-files-from-container-tp7587152p7587505.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Product Version functions

[Rob Mensching]

Always better to start with what you are trying to accomplish rather than
ask a very narrow question with no context.


On Mon, Jul 22, 2013 at 3:18 PM, Sean Farrow
wrote:

> Hi,
> I'm just in the process of writing a custom action, I know file version
> functions are in fileutil.cpp/h. Are Product version functions surfaced by
> WiX dutil?
> Regards
> Sean.
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [wix-users] Impact of installed burn?

[Rob Mensching]

The cool thing is that if you always use Bundles to install your MSI
packages, shared MSI packages will be correctly reference counted and only
removed when the last Bundle that needs it is removed. Totally avoids all
the bad behaviors.


On Tue, Jul 23, 2013 at 10:00 AM, Wesley Manning wrote:

> If the bundle exe is uninstalled it would uninstall the msi.  So you can
> install the standalone msi again after.  If you try to install msi after
> installing bundle exe the msi will not install as the bundle already
> installed it.
> If you install MSI and then install bundle exe then you'll see two entries
> in ARP.  There are other effects too such as if you install a newer version
> of the MSI with the bundle exe already installed it will upgrade the MSI.
>
> Not sure if this will present a problem other than aesthetics.  Should
> really use a MSI alone or burn alone and not mix the two.
>
> Wes
>
> -Original Message-
> From: Tomas Köhn [mailto:tomas.k...@cellavision.se]
> Sent: July-23-13 6:09 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] [wix-users] Impact of installed burn?
>
> Thanks,
>
> Will this impact future installs of .msi files which has been part of
> bundle before (but has been uninstalled)?
>
> / Tomas
>
> -Original Message-
> From: Wesley Manning [mailto:wmann...@dynagen.ca]
> Sent: den 22 juli 2013 14:40
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] [wix-users] Impact of installed burn?
>
> Users will have no way to uninstall burn package AFAIK.  See
> http://www.joyofsetup.com/2013/07/05/burn-zero-one-or-n/ .
>
> Wes
>
> -Original Message-
> From: Tomas Köhn [mailto:tomas.k...@cellavision.se]
> Sent: July-22-13 8:20 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] [wix-users] Impact of installed burn?
>
> We need to support installation from both .exe and .msi (for remote
> program distribution). As I understand, burn can't be used without
> installing into ARP. We want the program installation to be the same from
> both .exe and .msi.
>
> If I set DisableModify="yes" DisableRemove="yes", the bundle (burn)
> application will not be visible in Program & Feature. What will be stored
> in ARP and how will this impact the installed .msi?
>
> Regards
> Tomas
>
> --
> See everything from the browser to the database with AppDynamics Get
> end-to-end visibility with application monitoring from AppDynamics Isolate
> bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
> --
> See everything from the browser to the database with AppDynamics Get
> end-to-end visibility with application monitoring from AppDynamics Isolate
> bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> See everything from the browser to the database with AppDynamics Get
> end-to-end visibility with application monitoring from AppDynamics Isolate
> bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net

Re: [WiX-users] [wix-users] Impact of installed burn?

[Rob Mensching]

What conflicts are you worried about exactly? One or more specific user
scenarios that expose the issue you think there is in Burn would probably
help a lot.


On Wed, Jul 24, 2013 at 3:58 AM, Tomas Köhn wrote:

> I agree, burn has a lot of cool features.
>
> Our problem is that administrators expects an .msi for easy remote
> deployment, while other, smaller customers want to have an setup.exe with
> checks dependency (.NET framework, OS etc.).
>
> If we at first installs with setup.exe, we might later have to install
> .msi without conflicts and vice versa. If I understand correctly this is
> not possible with burn, which is a shame because it has everything we need
> and does it very well. What is a good alternative for this? dotNetInstaller?
>
> Regards
> Tomas
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: den 24 juli 2013 06:44
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] [wix-users] Impact of installed burn?
>
> The cool thing is that if you always use Bundles to install your MSI
> packages, shared MSI packages will be correctly reference counted and only
> removed when the last Bundle that needs it is removed. Totally avoids all
> the bad behaviors.
>
>
> On Tue, Jul 23, 2013 at 10:00 AM, Wesley Manning  >wrote:
>
> > If the bundle exe is uninstalled it would uninstall the msi.  So you
> > can install the standalone msi again after.  If you try to install msi
> > after installing bundle exe the msi will not install as the bundle
> > already installed it.
> > If you install MSI and then install bundle exe then you'll see two
> > entries in ARP.  There are other effects too such as if you install a
> > newer version of the MSI with the bundle exe already installed it will
> upgrade the MSI.
> >
> > Not sure if this will present a problem other than aesthetics.  Should
> > really use a MSI alone or burn alone and not mix the two.
> >
> > Wes
> >
> > -Original Message-
> > From: Tomas Köhn [mailto:tomas.k...@cellavision.se]
> > Sent: July-23-13 6:09 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] [wix-users] Impact of installed burn?
> >
> > Thanks,
> >
> > Will this impact future installs of .msi files which has been part of
> > bundle before (but has been uninstalled)?
> >
> > / Tomas
> >
> > -Original Message-
> > From: Wesley Manning [mailto:wmann...@dynagen.ca]
> > Sent: den 22 juli 2013 14:40
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] [wix-users] Impact of installed burn?
> >
> > Users will have no way to uninstall burn package AFAIK.  See
> > http://www.joyofsetup.com/2013/07/05/burn-zero-one-or-n/ .
> >
> > Wes
> >
> > -Original Message-
> > From: Tomas Köhn [mailto:tomas.k...@cellavision.se]
> > Sent: July-22-13 8:20 AM
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] [wix-users] Impact of installed burn?
> >
> > We need to support installation from both .exe and .msi (for remote
> > program distribution). As I understand, burn can't be used without
> > installing into ARP. We want the program installation to be the same
> > from both .exe and .msi.
> >
> > If I set DisableModify="yes" DisableRemove="yes", the bundle (burn)
> > application will not be visible in Program & Feature. What will be
> > stored in ARP and how will this impact the installed .msi?
> >
> > Regards
> > Tomas
> >
> > --
> >  See everything from the browser to the database with
> > AppDynamics Get end-to-end visibility with application monitoring from
> > AppDynamics Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.c
> > lktrk ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> >
> >
> > --
> >  See everything from the browser to the database with
> > AppDynamics Get end-to-end visibility with application monitoring from
> > AppDynamics Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro 

Re: [WiX-users] prompt for administrator account during major upgrade

[Rob Mensching]

Can you provide more details about how you are executing elevation?


On Wed, Jul 24, 2013 at 8:25 AM, Hoover, Jacob
wrote:

> Wix/Burn doesn't have a service portion written so it's dependent on
> Windows Installer constraints. If there is a need to update without admin
> privileges, either an Administrator must push the updates via a tool like
> SCCM/AD/etc, or the install/app would need to be reworked as a per-user
> application.
>
> -Original Message-
> From: Mike Myers [mailto:mike.my...@naucountry.com]
> Sent: Wednesday, July 24, 2013 10:02 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] prompt for administrator account during major upgrade
>
> I have a wix install with burn bootstrapper.  My situation deals with a
> non-administrator installing this on a machine.  The user is prompted for
> an administrator account.  When a major upgrade happens, the user is
> prompted for an administrator account again.  Is there any way to prevent a
> user from being prompted during the upgrade?
>
> Thanks
> -Mike
>
>
>
> This electronic message from NAU Country Insurance Company and any
> attachment to it is intended exclusively for the individual or entity to
> which it is addressed. It may contain information that is privileged,
> confidential and exempt from disclosure under applicable law. Any
> unauthorized disclosure, copying, distribution or use of this electronic
> message or any attachment is prohibited. If you have received this message
> in error, please return it to the sender and delete this original from your
> system.
>
> 3483950 - 24 Jul 2013 15:02:32 -
>
> --
> See everything from the browser to the database with AppDynamics Get
> end-to-end visibility with application monitoring from AppDynamics Isolate
> bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] prompt for administrator account during major upgrade

[Rob Mensching]

Sorry, missed the forks of this thread. Essentially what you are asking for
is that something on the system says, "This new version of the software is
safe because the old software is on the machine."  As Jacob mentioned there
are *a lot* of security issues to consider when implementing such a system.
We don't provide something like that in WiX toolset today.


On Wed, Jul 24, 2013 at 10:22 AM, Rob Mensching wrote:

> Can you provide more details about how you are executing elevation?
>
>
> On Wed, Jul 24, 2013 at 8:25 AM, Hoover, Jacob  > wrote:
>
>> Wix/Burn doesn't have a service portion written so it's dependent on
>> Windows Installer constraints. If there is a need to update without admin
>> privileges, either an Administrator must push the updates via a tool like
>> SCCM/AD/etc, or the install/app would need to be reworked as a per-user
>> application.
>>
>> -Original Message-
>> From: Mike Myers [mailto:mike.my...@naucountry.com]
>> Sent: Wednesday, July 24, 2013 10:02 AM
>> To: wix-users@lists.sourceforge.net
>> Subject: [WiX-users] prompt for administrator account during major upgrade
>>
>> I have a wix install with burn bootstrapper.  My situation deals with a
>> non-administrator installing this on a machine.  The user is prompted for
>> an administrator account.  When a major upgrade happens, the user is
>> prompted for an administrator account again.  Is there any way to prevent a
>> user from being prompted during the upgrade?
>>
>> Thanks
>> -Mike
>>
>>
>>
>> This electronic message from NAU Country Insurance Company and any
>> attachment to it is intended exclusively for the individual or entity to
>> which it is addressed. It may contain information that is privileged,
>> confidential and exempt from disclosure under applicable law. Any
>> unauthorized disclosure, copying, distribution or use of this electronic
>> message or any attachment is prohibited. If you have received this message
>> in error, please return it to the sender and delete this original from your
>> system.
>>
>> 3483950 - 24 Jul 2013 15:02:32 -
>>
>> --
>> See everything from the browser to the database with AppDynamics Get
>> end-to-end visibility with application monitoring from AppDynamics Isolate
>> bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>>
>> --
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [SPAM] Re: Patch bundle success when patch fails...

[Rob Mensching]

MSP didn't fail because Burn recognized it wasn't to be installed:

Planned package: cs201022_HotFix00,
state: Absent, default requested: Present, ba requested: Present, execute:
None, rollback: None, cache: No, uncache: No, dependency: None




On Wed, Jul 24, 2013 at 3:24 AM, rowbot  wrote:

> Hi,
>
> Can anyone tell my why a patch bundle installs successfully even though the
> patch inside didn't?
>
> If I run the MSP on an invalid RTM product, I get the usual message.
>
> >From the log:
>
> [07AC:0B2C][2013-07-24T11:14:47]i201: Planned package: cs201022_HotFix00,
> state: Absent, default requested: Present, ba requested: Present, execute:
> None, rollback: None, cache: No, uncache: No, dependency: None
> [07AC:0B2C][2013-07-24T11:14:47]i299: Plan complete, result: 0x0
> [07AC:0B2C][2013-07-24T11:14:47]i300: Apply begin
> [00FC:069C][2013-07-24T11:14:47]i360: Creating a system restore point.
> [00FC:069C][2013-07-24T11:15:07]i361: Created a system restore point.
> [00FC:069C][2013-07-24T11:15:07]i000: Caching bundle from:
>
> 'C:\Users\TESTMS~1.COR\AppData\Local\Temp\{ad69da17-a50e-47c4-95ff-071fd92c4d7c}\.be\cs2010_22_hf00.exe'
> to: 'C:\ProgramData\Package
> Cache\{ad69da17-a50e-47c4-95ff-071fd92c4d7c}\cs2010_22_hf00.exe'
> [00FC:069C][2013-07-24T11:15:07]i320: Registering bundle dependency
> provider: {ad69da17-a50e-47c4-95ff-071fd92c4d7c}, version: 2.2.0.0
> [07AC:0B2C][2013-07-24T11:15:07]i399: Apply complete, result: 0x0, restart:
> None, ba requested restart:  No
> [07AC:0B2C][2013-07-24T11:15:10]i500: Shutting down, exit code: 0x0
>
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patch-bundle-success-when-patch-fails-tp7587538.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [SPAM] Re: [SPAM] Re: Wix 3.7 Burn error '0x80004005: Failed to extract all files from container.'

[Rob Mensching]

Hmm, well, certainly seems to be something going wrong but can't tell what
exactly based on the log files. Would be a great idea to open a bug with as
many details about the issue as possible.


On Wed, Jul 24, 2013 at 5:06 AM, TimM  wrote:

> Sorry about that
>
> Try this link: https://www.dropbox.com/s/5ersyy950w54fdy/ErrorLogfile.zip
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-3-7-Burn-error-0x80004005-Failed-to-extract-all-files-from-container-tp7587152p7587541.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Error launching bootstrapper

[Rob Mensching]

And what version of WiX v3.8?


On Thu, Jul 25, 2013 at 6:59 AM, David Watson  wrote:

> What error?
>
> -Original Message-
> From: Pasquale Fersini [mailto:basquale.fers...@gmail.com]
> Sent: 25 July 2013 14:42
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] Error launching bootstrapper
>
> Hi all,
> on a user machine (Windows XP SP3) our setup, compiled with wix 3.8,
> doesn't
> start, immediately going into error. No log possible. Double click
> -> Error.
> I don't know...
>
> Ideas?
>
> Regards,
> Pasquale.
>
> -
> -
> See everything from the browser to the database with AppDynamics Get
> end-to-end visibility with application monitoring from AppDynamics Isolate
> bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> SDL PLC confidential, all rights reserved.
> If you are not the intended recipient of this mail SDL requests and
> requires that you delete it without acting upon or copying any of its
> contents, and we further request that you advise us.
> SDL PLC is a public limited company registered in England and Wales.
>  Registered number: 02675207.
> Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6
> 7DY, UK.
>
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [wix-users] Impact of installed burn?

[Rob Mensching]

There won't be version conflicts, the MSIs will behave the way they always
do. The only question is how many APR entries you end up with. In some
cases, you may end up with two ARP entries.  That's necessary because the
Burn engine will cache the MSI (which greatly improves install success
rates and definitely helps with future repair and patching [if you use
patching]).

1. The bundle in this case will very quickly install (but not really do
anything), because the MSI is already present on the machine. The bundle
will be registered in ARP with the MSI. That's not the ideal but
uninstalling will work correctly in all cases. Again, ARP entry is
necessary for the bundle to clean up the package cache (which is used
because it provides such higher success rates).

If the bundle is carrying a newer version, the old MSI can be removed
(depends on your upgrade logic) and the bundle will be the only thing
registered.

2. In this case, the MSI will show the standard modify dialog because it
will find it is already installed (by the bundle). You'll still only end up
with one ARP entry. If the MSI is newer, then it can upgrade the MSI that
the bundle installed. This will not remove the bundle ARP entry but it can
be removed (it will clean up it's package cache) and the newer MSI will
stay.

Basically, the bundle will ensure there is an ARP entry to itself so it can
clean up the package cache. This design is in place because the package
cache provides such success benefits.


On Thu, Jul 25, 2013 at 4:20 AM, Tomas Köhn wrote:

> Thank you your replay.
>
> I'm worried about the following scenarios:
> * Administrators installs the program with the .msi file (their preferred
> method). Later a user installs the program using setup.exe (burn)
> * Users installs the setup.exe (burn), later administrators installs the
> program (same version or different version) using the .msi file.
>
> I'm worried about version conflicts because setup.exe (burn) have
> references to the .msi file (setup.exe, burn only contains a single .msi).
>
> / Tomas
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: den 24 juli 2013 19:20
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] [wix-users] Impact of installed burn?
>
> What conflicts are you worried about exactly? One or more specific user
> scenarios that expose the issue you think there is in Burn would probably
> help a lot.
>
>
> On Wed, Jul 24, 2013 at 3:58 AM, Tomas Köhn  >wrote:
>
> > I agree, burn has a lot of cool features.
> >
> > Our problem is that administrators expects an .msi for easy remote
> > deployment, while other, smaller customers want to have an setup.exe
> > with checks dependency (.NET framework, OS etc.).
> >
> > If we at first installs with setup.exe, we might later have to install
> > .msi without conflicts and vice versa. If I understand correctly this
> > is not possible with burn, which is a shame because it has everything
> > we need and does it very well. What is a good alternative for this?
> dotNetInstaller?
> >
> > Regards
> > Tomas
> >
> > -Original Message-
> > From: Rob Mensching [mailto:r...@robmensching.com]
> > Sent: den 24 juli 2013 06:44
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] [wix-users] Impact of installed burn?
> >
> > The cool thing is that if you always use Bundles to install your MSI
> > packages, shared MSI packages will be correctly reference counted and
> > only removed when the last Bundle that needs it is removed. Totally
> > avoids all the bad behaviors.
> >
> >
> > On Tue, Jul 23, 2013 at 10:00 AM, Wesley Manning  > >wrote:
> >
> > > If the bundle exe is uninstalled it would uninstall the msi.  So you
> > > can install the standalone msi again after.  If you try to install
> > > msi after installing bundle exe the msi will not install as the
> > > bundle already installed it.
> > > If you install MSI and then install bundle exe then you'll see two
> > > entries in ARP.  There are other effects too such as if you install
> > > a newer version of the MSI with the bundle exe already installed it
> > > will
> > upgrade the MSI.
> > >
> > > Not sure if this will present a problem other than aesthetics.
> > > Should really use a MSI alone or burn alone and not mix the two.
> > >
> > > Wes
> > >
> > > -Original Message-
> > > From: Tomas Köhn [mailto:tomas.k...@cellavision.se]
> > > Sent: July-23-13 6:09 AM
> > > To: General discussion 

Re: [WiX-users] Custom action [P]

[Rob Mensching]

Slight amendment: "You should NOT call any custom actions **that modify
machine state Before InstallInitialize or** After InstallFinalize "


On Thu, Jul 25, 2013 at 6:08 AM, Steven Ogilvie wrote:

> Classification: Public
> You should NOT call any custom actions After InstallFinalize.
>
> -Original Message-
> From: Chaitanya Sanapala [PC-BLR-DEV] [mailto:chaita...@pointcross.com]
> Sent: July-25-13 4:56 AM
> To: WiX-users@lists.sourceforge.net
> Subject: [WiX-users] Custom action
>
> Hi,
>
> I'am using wix 3.5,I am using customa action for installing the IIS files.
> some of the custom actions is in Before Install Finalize & some are from
> after install finalize I'm using some of files to install after
> Installfinalize through custom action.
> At that time custom action is calling the command prompt and throwing the
> Finish window out of the screen..
> I want to know how to avoid that..???
> Is is there any timer to set the custom action to call???
>
> Regards,
> chaitanya
>
>
>
> --
> See everything from the browser to the database with AppDynamics Get
> end-to-end visibility with application monitoring from AppDynamics Isolate
> bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> This message has been marked as Public by Steven Ogilvie on July-25-13
> 9:08:18 AM.
>
> The above classification labels were added to the message by TITUS Message
> Classification. For more information visit www.titus.com.
>
>
>
>
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Uninstall on W7 with activated UAC from ARP: No UAC elevation prompt

[Rob Mensching]

It's ARP being magical. Never quite tracked down how they did it.

Fortunately, Burn is smart enough to recognize that it is already elevated
and doesn't ask again. 


On Thu, Jul 25, 2013 at 3:55 AM, Tobias S  wrote:

> Any idea on that behavior? Feedback highly appreciated.
>
> Best regards,
> Tobias
>
>
> 2013/7/16 Tobias S 
>
> > Hi,
> >
> > Didn't find any answer related to this on the mailing list yet.
> >
> > Have following behavior on Win7 VMs with Custom BAL as well as when using
> > BootstrapperApplicationRef Id="
> > WixStandardBootstrapperApplication.RtfLicense". There is no UAC prompt
> > when uninstalling a bundle from ARP. When doing the same with a
> standalone
> > MSI deployed with the bundle there is one as expected.
> >
> > Mean as the installation is working properly I don't care about that
> > behavior but I definitely would expect an UAC prompt here. Any clue why
> > this is not show here? Is the OS doing here something like "Ah this user
> > installed the package so I don't need to ask him again whether it is ok
> to
> > uninstall it" ?
> >
> > Thanks and best regards,
> > Tobias
> >
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] VS 2013 support

[Rob Mensching]

And since I was explicitly called out, old tweet:
https://twitter.com/robmen/status/352808666338033664


On Thu, Jul 25, 2013 at 8:54 AM, Hoover, Jacob
wrote:

> Since Wix is open source and community driven, I am sure someone will make
> it work with VS2013 once it is RTM.  A beta/preview is open for things to
> change, so I doubt anyone would have undergone the effort as of yet.
>
> -Original Message-
> From: Ivanoff, Alex [mailto:alex.ivan...@shavlik.com]
> Sent: Thursday, July 25, 2013 10:46 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] VS 2013 support
>
> Anyone?
>
>
> On Jul 17, 2013, at 9:50, "Ivanoff, Alex" 
> wrote:
>
> > Rob,
> >
> > Do you plan VS 2013 support?
> >
> >
> > On Jul 16, 2013, at 9:08, "Ivanoff, Alex" 
> wrote:
> >
> >> I did some tests. Neither 3.8 nor 4.0 provide VS 2013 integration. Are
> you planning it? Which version?
> >>
> >>
> >> On Jul 15, 2013, at 14:24, "Ivanoff, Alex" 
> wrote:
> >>
> >>> Is there a version of WiX that supports VS 2013?
> >>
> >> -
> >> - See everything from the browser to the database with
> >> AppDynamics Get end-to-end visibility with application monitoring
> >> from AppDynamics Isolate bottlenecks and diagnose root cause in
> >> seconds.
> >> Start your free trial of AppDynamics Pro today!
> >> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.
> >> clktrk ___
> >> WiX-users mailing list
> >> WiX-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> > --
> >  See everything from the browser to the database with
> > AppDynamics Get end-to-end visibility with application monitoring from
> > AppDynamics Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.c
> > lktrk ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> See everything from the browser to the database with AppDynamics Get
> end-to-end visibility with application monitoring from AppDynamics Isolate
> bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [SPAM] Re: Patch bundle success when patch fails...

[Rob Mensching]

Get a BA that recognizes that as a failure condition? Or, if you are using
wixstdba, help us extend wixstdba to treat that as a failure condition. The
Burn engine is doing as it is told.


On Thu, Jul 25, 2013 at 1:25 AM, rowbot  wrote:

> Okay, but given the scenario when a bundle contains only one MSP, this
> doesn't seem good...
>
> How can I get it to fail the bundle?
>
> Otherwise, I get a bundle ARP entry but no patch installed...
>
> Thanks,
>
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patch-bundle-success-when-patch-fails-tp7587538p7587570.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Error launching bootstrapper

[Rob Mensching]

Hmm, where did you get that build from? There is no WiX v3.8.5506 build.


On Thu, Jul 25, 2013 at 9:15 AM, Pasquale Fersini <
basquale.fers...@gmail.com> wrote:

> Application error
>
> Wix 3.8.5506.0
>
>
> 2013/7/25 Rob Mensching 
>
> > And what version of WiX v3.8?
> >
> >
> > On Thu, Jul 25, 2013 at 6:59 AM, David Watson  wrote:
> >
> > > What error?
> > >
> > > -Original Message-
> > > From: Pasquale Fersini [mailto:basquale.fers...@gmail.com]
> > > Sent: 25 July 2013 14:42
> > > To: General discussion for Windows Installer XML toolset.
> > > Subject: [WiX-users] Error launching bootstrapper
> > >
> > > Hi all,
> > > on a user machine (Windows XP SP3) our setup, compiled with wix 3.8,
> > > doesn't
> > > start, immediately going into error. No log possible. Double click
> > > -> Error.
> > > I don't know...
> > >
> > > Ideas?
> > >
> > > Regards,
> > > Pasquale.
> > >
> > >
> >
> -
> > > -
> > > See everything from the browser to the database with AppDynamics Get
> > > end-to-end visibility with application monitoring from AppDynamics
> > Isolate
> > > bottlenecks and diagnose root cause in seconds.
> > > Start your free trial of AppDynamics Pro today!
> > >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > > ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > > SDL PLC confidential, all rights reserved.
> > > If you are not the intended recipient of this mail SDL requests and
> > > requires that you delete it without acting upon or copying any of its
> > > contents, and we further request that you advise us.
> > > SDL PLC is a public limited company registered in England and Wales.
> > >  Registered number: 02675207.
> > > Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire
> > SL6
> > > 7DY, UK.
> > >
> > >
> > >
> > >
> >
> --
> > > See everything from the browser to the database with AppDynamics
> > > Get end-to-end visibility with application monitoring from AppDynamics
> > > Isolate bottlenecks and diagnose root cause in seconds.
> > > Start your free trial of AppDynamics Pro today!
> > >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > > ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> > >
> >
> >
> --
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [SPAM] Re: [SPAM] Re: [SPAM] Re: Wix 3.7 Burn error '0x80004005: Failed to extract all files from container.'

[Rob Mensching]

Arg! I thought that bug was fixed to give a better error message. Jacob, if
you're still interested, that's the bug to fix. To implement a better error
message in the log that I thought was already there.   Interested?


On Thu, Jul 25, 2013 at 10:17 AM, TimM  wrote:

> Okay we think we have this fixed now.
>
> Our MSBuild target file had the following:
>
>   
>  TaskAction="StringToItemCol" ItemString="$(TargetPath)" Separator=";">
>   
> 
>Condition="'$(SignThisFile)' != 'false'"
>   Command = '"$(SignToolCommand)" $(SignToolArgs) /d
> "%(TargetPathItem.filename)%(TargetPathItem.extension)"
> "%(TargetPathItem.Identity)"'
> />
>   
>
> and this was causing the issue. We change it to the following and so far it
> seems to be working:
>
>   
>Condition="'$(SignThisFile)' != 'false'"
>   Command = '"$(SignToolCommand)" $(SignToolArgs) "@(SignBundle)"'
> />
>   
>
>   
>Condition="'$(SignThisFile)' != 'false'"
>   Command = '"$(SignToolCommand)" $(SignToolArgs)
> "@(SignBundleEngine)"'
> />
>   
>
> We'll do a bit more testing to verify, but so far it seems to have fixed
> the
> issue.
>
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-3-7-Burn-error-0x80004005-Failed-to-extract-all-files-from-container-tp7587152p7587595.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn Addons - reevalulate and uninstall addon bundle on main bundle install

[Rob Mensching]

Addons (and patch) bundles follow the main bundle (more written here:
https://support.firegiant.com/entries/24024208-Bundle-chain-execution-order-).
To get the behavior you want, you'd need an upgrade relationship.

I think a custom BA could override the default behaviors without using an
upgrade relationship but I'd try to use the upgrade relationship first.


On Thu, Jul 25, 2013 at 1:32 PM, Wesley Manning  wrote:

> I'm using wixstba and I have a addon bundle that I want to uninstall when
> a certain version of my main bundle is installed (and prevent install if
> this main bundle is present).
>
> I'm using a registry search and bal:condition in the addon to do this.
>  Looks like the bal:condition does not do the job.  It works to block
> install when I try to install the addon when the main bundle is already
> installed.  But does not uninstall the addon when the main bundle it
> installed.
>
> Any idea on what I do to have the addon uninstall when the main bundle
> installs?  I'm using RTM version of Wix 3.7.
>
> Wes
>
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] MSMQ Extension and schema

[Rob Mensching]

Did you also add a reference to the extension?


On Thu, Jul 25, 2013 at 2:04 PM, Drake, David wrote:

> I'm working on creating a new installer for a self-hosted web service and
> there are a couple of things I'm hoping there's an easier way to handle.
>  For this thread, I'm interested in the MSMQ Extension:
>
> Where did the MSMQ Extension go?  I see pages out there that talk about
> being able to add the following:
> xmlns:msmq="http://schemas.microsoft.com/wix/MsmqExtension";
> but doing so via VS2012 with Wix 3.7.1224.0 does not give me any sort of
> auto complete when I start creating any of the MSMQ related nodes.  I don't
> even see the namespace show up.  Did it get removed?
>
> ~David Drake
> CES Build Engineer
> david.dr...@wizards.com
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] MSMQ Extension and schema

[Rob Mensching]

I think there were a couple bugs opened on that fixed in v3.8.


On Thu, Jul 25, 2013 at 2:25 PM, Drake, David wrote:

> I think I've already found out what was wrong.  I created my WIX Resource
> directory via the wix3.7-binaries.zip download, not by copying from the
> Program Files installed directory, and the .zip is missing a few things, to
> include Wix.ComPlusExtension.bll and WixMsmqExtension.dll.
>
> Since the .zip and my installed directories both have the same version,
> I'll go ahead and copy those files over which solves my immediate problem.
>
> This does mean that the Wix installer and binaries.zip files seem to have
> some differences as of version 3.7.1224.0.
>
>
> ~David Drake
> CES Build Engineer
> david.dr...@wizards.com
>
>
>
> -Original Message-
> From: Drake, David [mailto:david.dr...@wizards.com]
> Sent: Thursday, July 25, 2013 14:05 PM
> To: General discussion for Windows Installer XML toolset. (
> wix-users@lists.sourceforge.net)
> Subject: [WiX-users] MSMQ Extension and schema
>
> I'm working on creating a new installer for a self-hosted web service and
> there are a couple of things I'm hoping there's an easier way to handle.
>  For this thread, I'm interested in the MSMQ Extension:
>
> Where did the MSMQ Extension go?  I see pages out there that talk about
> being able to add the following:
> xmlns:msmq="http://schemas.microsoft.com/wix/MsmqExtension";
> but doing so via VS2012 with Wix 3.7.1224.0 does not give me any sort of
> auto complete when I start creating any of the MSMQ related nodes.  I don't
> even see the namespace show up.  Did it get removed?
>
> ~David Drake
> CES Build Engineer
> david.dr...@wizards.com
>
>
> --
> See everything from the browser to the database with AppDynamics Get
> end-to-end visibility with application monitoring from AppDynamics Isolate
> bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn Addons - reevalulate and uninstall addon bundle on main bundle install

[Rob Mensching]

Actually, if your addon's aren't backwards compatible any longer it sounds
like you should change the addon related id. That way, when the old version
of the main bundle is removed, it will take the old addons with it since
the new main bundle says it isn't related to them.


On Thu, Jul 25, 2013 at 8:50 PM, Wesley Manning  wrote:

> Sorry, I didn't explain it well enough.  Most of the time I want the addon
> bundles to act like an addons: gets uninstalled when main bundle is
> uninstalled, etc.  But there are times when upgrading the main bundle,
> older addons are no longer valid.  Then I want to remove them.
>
> Reason is I would like to use addons to install features that extend our
> main software.  Then customers can pick and choose functionality.  There
> are times when our main software changes such that older addons will no
> longer work so I like to remove those on an upgrade (or on a new install if
> user has incompatible addons installed).
>
> Any comments on this scenario?  Looks like I can't get both behaviours
> unless I use custom BA?  Maybe this is like an addon and an upgrade in one.
>  :)  Am I abusing the addon feature?
>
> Wes
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: July 25, 2013 5:46 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Burn Addons - reevalulate and uninstall addon
> bundle on main bundle install
>
> Addons (and patch) bundles follow the main bundle (more written here:
>
> https://support.firegiant.com/entries/24024208-Bundle-chain-execution-order-
> ).
> To get the behavior you want, you'd need an upgrade relationship.
>
> I think a custom BA could override the default behaviors without using an
> upgrade relationship but I'd try to use the upgrade relationship first.
>
>
> On Thu, Jul 25, 2013 at 1:32 PM, Wesley Manning 
> wrote:
>
> > I'm using wixstba and I have a addon bundle that I want to uninstall
> > when a certain version of my main bundle is installed (and prevent
> > install if this main bundle is present).
> >
> > I'm using a registry search and bal:condition in the addon to do this.
> >  Looks like the bal:condition does not do the job.  It works to block
> > install when I try to install the addon when the main bundle is
> > already installed.  But does not uninstall the addon when the main
> > bundle it installed.
> >
> > Any idea on what I do to have the addon uninstall when the main bundle
> > installs?  I'm using RTM version of Wix 3.7.
> >
> > Wes
> >
> >
> >
> > --
> >  See everything from the browser to the database with
> > AppDynamics Get end-to-end visibility with application monitoring from
> > AppDynamics Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.c
> > lktrk ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
>
> --
> See everything from the browser to the database with AppDynamics Get
> end-to-end visibility with application monitoring from AppDynamics Isolate
> bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Error launching bootstrapper

[Rob Mensching]

There were issues a while ago with Windows XP builds. I believe they were
all fixed. Maybe that build is old enough to have the issue. Try a later
build and see if that helps.


On Fri, Jul 26, 2013 at 12:18 AM, Pasquale Fersini <
basquale.fers...@gmail.com> wrote:

> Sorry Rob,
> but I take that number version when I was drunk. May be 3.8.506.0 ?
>
> Thanks.
>
>
> 2013/7/25 Rob Mensching 
>
> > Hmm, where did you get that build from? There is no WiX v3.8.5506 build.
> >
> >
> > On Thu, Jul 25, 2013 at 9:15 AM, Pasquale Fersini <
> > basquale.fers...@gmail.com> wrote:
> >
> > > Application error
> > >
> > > Wix 3.8.5506.0
> > >
> > >
> > > 2013/7/25 Rob Mensching 
> > >
> > > > And what version of WiX v3.8?
> > > >
> > > >
> > > > On Thu, Jul 25, 2013 at 6:59 AM, David Watson 
> wrote:
> > > >
> > > > > What error?
> > > > >
> > > > > -Original Message-
> > > > > From: Pasquale Fersini [mailto:basquale.fers...@gmail.com]
> > > > > Sent: 25 July 2013 14:42
> > > > > To: General discussion for Windows Installer XML toolset.
> > > > > Subject: [WiX-users] Error launching bootstrapper
> > > > >
> > > > > Hi all,
> > > > > on a user machine (Windows XP SP3) our setup, compiled with wix
> 3.8,
> > > > > doesn't
> > > > > start, immediately going into error. No log possible. Double click
> > > > > -> Error.
> > > > > I don't know...
> > > > >
> > > > > Ideas?
> > > > >
> > > > > Regards,
> > > > > Pasquale.
> > > > >
> > > > >
> > > >
> > >
> >
> -
> > > > > -
> > > > > See everything from the browser to the database with AppDynamics
> Get
> > > > > end-to-end visibility with application monitoring from AppDynamics
> > > > Isolate
> > > > > bottlenecks and diagnose root cause in seconds.
> > > > > Start your free trial of AppDynamics Pro today!
> > > > >
> > > >
> > >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > > > > ___
> > > > > WiX-users mailing list
> > > > > WiX-users@lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > > > > SDL PLC confidential, all rights reserved.
> > > > > If you are not the intended recipient of this mail SDL requests and
> > > > > requires that you delete it without acting upon or copying any of
> its
> > > > > contents, and we further request that you advise us.
> > > > > SDL PLC is a public limited company registered in England and
> Wales.
> > > > >  Registered number: 02675207.
> > > > > Registered address: Globe House, Clivemont Road, Maidenhead,
> > Berkshire
> > > > SL6
> > > > > 7DY, UK.
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> --
> > > > > See everything from the browser to the database with AppDynamics
> > > > > Get end-to-end visibility with application monitoring from
> > AppDynamics
> > > > > Isolate bottlenecks and diagnose root cause in seconds.
> > > > > Start your free trial of AppDynamics Pro today!
> > > > >
> > > >
> > >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > > > > ___
> > > > > WiX-users mailing list
> > > > > WiX-users@lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
> --
> > > > See everything from the browser to the database with AppDynamics
> > > > Get end-to-end visibility with application monitoring from
> AppDynamics
> > > > Isolate bottlenecks and diagnos

Re: [WiX-users] Burn Addons - reevalulate and uninstall addon bundle on main bundle install

[Rob Mensching]

Yes, yes. 


On Fri, Jul 26, 2013 at 6:30 AM, Wesley Manning  wrote:

> Yes, OK, thanks.  I did that and was getting confused because my test was:
> --- clean machine: install old addon
> --- install new (incompatible) main bundle
> I thought the addon should be removed (but it won't be since it's not
> related to the new bundle).  So then I thought I need to use an install
> condition on addon.
>
> I was making things too complicated.  I just have to prevent the addon(s)
> being installed if the correct bundle is not installed.  Then I will have
> no problems.
>
> Wes
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: July-26-13 1:03 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Burn Addons - reevalulate and uninstall addon
> bundle on main bundle install
>
> Actually, if your addon's aren't backwards compatible any longer it sounds
> like you should change the addon related id. That way, when the old version
> of the main bundle is removed, it will take the old addons with it since
> the new main bundle says it isn't related to them.
>
>
> On Thu, Jul 25, 2013 at 8:50 PM, Wesley Manning 
> wrote:
>
> > Sorry, I didn't explain it well enough.  Most of the time I want the
> > addon bundles to act like an addons: gets uninstalled when main bundle
> > is uninstalled, etc.  But there are times when upgrading the main
> > bundle, older addons are no longer valid.  Then I want to remove them.
> >
> > Reason is I would like to use addons to install features that extend
> > our main software.  Then customers can pick and choose functionality.
> > There are times when our main software changes such that older addons
> > will no longer work so I like to remove those on an upgrade (or on a
> > new install if user has incompatible addons installed).
> >
> > Any comments on this scenario?  Looks like I can't get both behaviours
> > unless I use custom BA?  Maybe this is like an addon and an upgrade in
> one.
> >  :)  Am I abusing the addon feature?
> >
> > Wes
> >
> > -Original Message-
> > From: Rob Mensching [mailto:r...@robmensching.com]
> > Sent: July 25, 2013 5:46 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Burn Addons - reevalulate and uninstall addon
> > bundle on main bundle install
> >
> > Addons (and patch) bundles follow the main bundle (more written here:
> >
> > https://support.firegiant.com/entries/24024208-Bundle-chain-execution-
> > order-
> > ).
> > To get the behavior you want, you'd need an upgrade relationship.
> >
> > I think a custom BA could override the default behaviors without using
> > an upgrade relationship but I'd try to use the upgrade relationship
> first.
> >
> >
> > On Thu, Jul 25, 2013 at 1:32 PM, Wesley Manning 
> > wrote:
> >
> > > I'm using wixstba and I have a addon bundle that I want to uninstall
> > > when a certain version of my main bundle is installed (and prevent
> > > install if this main bundle is present).
> > >
> > > I'm using a registry search and bal:condition in the addon to do this.
> > >  Looks like the bal:condition does not do the job.  It works to
> > > block install when I try to install the addon when the main bundle
> > > is already installed.  But does not uninstall the addon when the
> > > main bundle it installed.
> > >
> > > Any idea on what I do to have the addon uninstall when the main
> > > bundle installs?  I'm using RTM version of Wix 3.7.
> > >
> > > Wes
> > >
> > >
> > >
> > > 
> > > --
> > >  See everything from the browser to the database with
> > > AppDynamics Get end-to-end visibility with application monitoring
> > > from AppDynamics Isolate bottlenecks and diagnose root cause in
> seconds.
> > > Start your free trial of AppDynamics Pro today!
> > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg
> > > .c lktrk ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> > >
> >
> > --
> >  See everything from the browser to the database with
>

Re: [WiX-users] Burn and MultiInstance

[Rob Mensching]

Cool. Two things:

1. Let's start the assignment agreement process (
http://wixtoolset.org/about/assignment-agreement/).

2. Let's have this conversation on wix-devs. That's more appropriate.


On Mon, Jul 29, 2013 at 5:38 AM,  wrote:

> Hello,
>
> I have been tasked with discovering if I can get Burn to support
> multi instance installs and was wondering if you all could point me in the
> direction I should start looking.
>
> Tyler Reid | Operations and Infrastructure | Accenture Software | P&C
> Insurance
> 1807 Jones Street | Bolivar, MO 65613| USA
> Office: +cc.xxx.xxx. | Fax: 417.777.3792
> E-Mail: tyler.w.r...@accenture.com |
> www.accenture.com/pcsoftware
>
>
>
> 
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise confidential information. If you have
> received it in error, please notify the sender immediately and delete the
> original. Any other use of the e-mail by you is prohibited.
>
> Where allowed by local law, electronic communications with Accenture and
> its affiliates, including e-mail and instant messaging (including content),
> may be scanned by our systems for the purposes of information security and
> assessment of internal compliance with Accenture policy.
>
>
> __
>
> www.accenture.com
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [SPAM] Re: Unattended upgrade of Burn package

[Rob Mensching]

Look in the Bundle's log file. It'll show what was installed. If anything
per-machine was installed, it will have to elevate.


On Tue, Jul 30, 2013 at 1:14 AM, David Watson  wrote:

> I don't think burn currently supports this kind of scenario well (it may
> but
> I am not an expert).
>
> What you could do is make a per-user burn bundle that just installs your
> msi
> silently then add that as an .exe package to your main with-prerequisites
> bundle.
>
> Or indeed leave it the way you have it and maybe flag the upgradable msi as
> visible in ARP and supply the msi directly when you service it.
>
> Or you could work out how burn is deciding to show the UAC prompt and fix
> it
> so it works in your scenario if possible.
>
> Dave
>
> -Original Message-
> From: dave [mailto:d...@swordfishsoftware.co.nz]
> Sent: 30 July 2013 06:02
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Unattended upgrade of Burn package
>
> I'd like to use Burn to install multiple pre-requisites (VC++ redist,
> console
> app) and two desktop application msi packages. One of these desktop
> applications is a client program to be remotely upgraded without elevation.
> I have it installing to LocalAppData and major upgrades work fine without
> elevation.
>
> Now, can I install this client app via Burn and then run a major upgrade on
> it using just the msi package? I have installed via Burn with the
> pre-requisites and this raises UAC as expected. I ran a major upgrade using
> just the msi and this performed as expected but put a new entry into
> Programs
> and Features.
>
> I cannot run the complete burn bundle as a major upgrade in quiet mode as
> this raises the UAC prompt, even though only the client app is updated
> with a
> new version.
>
> Is this even possible? How do I go about it?
>
> My bundle:
>
> - VC++ redist (installed via burn)
> - console app (requires elevation, installed via burn)
> - client app (DOESN'T require elevation, installed via burn) <- I want to
> upgrade this silently either with burn or msi
> - server app (requires elevation, installed via burn)
>
> Thanks
>
> Dave
>
>
>
> --
> View this message in context:
>
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Unattended-upgr
> ade-of-Burn-package-tp7587678.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> -
> -
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught
> up. So what steps can you take to put your SQL databases under version
> control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> SDL PLC confidential, all rights reserved.
> If you are not the intended recipient of this mail SDL requests and
> requires that you delete it without acting upon or copying any of its
> contents, and we further request that you advise us.
> SDL PLC is a public limited company registered in England and Wales.
>  Registered number: 02675207.
> Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6
> 7DY, UK.
>
>
>
> --
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Bootstrapper -- Can it be UI-less?

[Rob Mensching]

It can be UI-less if your BA doesn't show UI.


On Tue, Jul 30, 2013 at 8:00 AM, Tom -  wrote:

> Good afternoon,
>
> >From my previous problems, I pieced together a bootstrapper that should
> do nothing but uninstall a non-WiX installation of a program. I don't need
> the bootstrapper UI. I wouldn't mind it, I guess, had it looked the
> slightest like the other UI:s in WiX and Windows, but now I want to
> suppress it and have it do its check (it doesn't throw any exceptions) and
> then proceed with the "real" installer. Or copy my other installer UI into
> the bootstrapper and make that the only visible UI. I wouldn't be so lucky
> that it is that simple, is it? :-)
>
> Best Regards,
>
> Tom
>
>
> --
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] wixtoolset.org down?

[Rob Mensching]

Should be back now. AppPool was dead, I'll ask why.


On Tue, Jul 30, 2013 at 8:42 AM, Alain Forget  wrote:

> +1
>
> -Original Message-
> From: Tony [mailto:yellowjacketl...@gmail.com]
> Sent: Tuesday, July 30, 2013 11:36
> To: WiX Users
> Subject: [WiX-users] wixtoolset.org down?
>
> I get a 503 when I attempt to browse to wixtoolset.org, is it down for
> maintenance?
>
> --
> Tony
>
> --
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> --
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] adding event source during install

[Rob Mensching]

I like that way.


On Fri, Aug 2, 2013 at 12:51 PM, Tony White  wrote:

> I don't really understand your suggestion.
> I have 18 tabs of google searches open, and reading the WiX help, and
> looking at the source code for four days now.
> Finally found this:
> http://stackoverflow.com/questions/16946701/wix-installer-how-can-i-show-the-value-of-manufacturer-in-the-install-path
>
> I'm sure this is not the way to do it, but it does have the redeeming
> quality of working:
>
> 
> 
>  Name="!(bind.property.Manufacturer)">
>  Name="!(bind.property.ProductName)">
> 
> 
> 
>
> Thanks,
>
> Tony
>
> -Original Message-
> From: John Cooper [mailto:jocoo...@jackhenry.com]
> Sent: Friday, August 02, 2013 11:22 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] adding event source during install
>
> It means what it says.  There's already a Manufacturer property.  I use
> the Directory@Id "CompanyFolder".  Rather than go through all the
> machinations, use WixUI_InstallDir and let it adjust your INSTALLLOCATION.
>
> There's documentation on this in both the WiX help and the on-line
> tutorials.
>
> --
> 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: Tony White [mailto:twh...@ent.com]
> Sent: Friday, August 02, 2013 12:08 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] adding event source during install
>
> The goal is to set the installation directory to C:\Program Files\Ent
> Federal Credit Union\ProductName
>
> This produces a build error:
> 
>  Name="ProgramFiles">
>  Name="Company">
>  Name="LogonTimerService">
> 
> 
> 
> Error   2   ICE99: The directory name: Manufacturer is the same as one
> of the MSI Public Properties and can cause unforeseen side effects.
>
> I found somewhere that using a custom action I could set a directory value
> using the [Manufacturer] property.
> Is there another way?
>
> Thanks,
>
> Tony
>
> -Original Message-
> From: John Cooper [mailto:jocoo...@jackhenry.com]
> Sent: Wednesday, July 31, 2013 4:34 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] adding event source during install
>
> Why are you setting TARGETDIR with a custom action?This is not usually
> a good practice, and overriding TARGETDIR is usually reserved for
> activities like admin installs.  If you want to set up a variable
> InstallLocation, there are much better patterns to follow to achieve this.
>
> --
> 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: Tony White [mailto:twh...@ent.com]
> Sent: Wednesday, July 31, 2013 5:24 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] adding event source during install
>
> >From the log file it seems my custom action that sets the TARGETDIR is
> the thing throwing the error:
>
> Action 16:03:18: SetTARGETDIR.
> Action start 16:03:18: SetTARGETDIR.
> MSI (c) (58:18) [16:03:18:241]: PROPERTY CHANGE: Modifying TARGETDIR
> property. Its current value is 'C:\'. Its new value: 'C:\Program Files\Ent
> Federal Credit Union\'.
> MSI (c) (58:18) [16:03:18:241]: Note: 1: 1324 2: ? 3: 1 MSI (c) (58:18)
> [16:03:18:241]: Note: 1: 2205 2:  3: Error MSI (c) (58:18) [16:03:18:241]:
> Note: 1: 2228 2:  3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` =
> 1324 Error 1324. The folder path '?' contains an invalid character.
> MSI (c) (58:18) [16:03:23:420]: Note: 1: 2205 2:  3: Error MSI (c) (58:18)
> [16:03:23:420]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` FROM `Error`
> WHERE `Error` = 1709 MSI (c) (58:18) [16:03:23:420]: Product:
> LogonTimerService -- Error 1324. The folder path '?' contains an invalid
> character.
>
> Action ended 16:03:23: SetTARGETDIR. Return value 3.
> MSI (c) (58:18) [16:03:23:422]: Doing action: FatalError
>
>
>  Value="[ProgramFiles64Folder][Manufacturer]" Return="check" />
> 
>  />
> 
>
> So then the question is. Why does adding the EventSource node cause the
> custom action to fail?
> I'm going to get another log with the EventSource removed and see what is
> different.
>
> Thanks,
>
> Tony
> -Original Message-
> From: John Cooper [mailto:jocoo...@jackhenr

[WiX-users] [SPAM] Re: Wix BURN (wpf) and UAC promt

[Rob Mensching]

Note: that can confuse Burn because it is designed to not run the BA
elevated.


On Sat, Aug 3, 2013 at 9:36 AM, Phill Hogland  wrote:

> The implication that I take from your questions is that you are trying to
> write something to the Program Files area from the bootstrapper.  Generally
> I think folks would encourage you to rethink the security implications of
> doing this and use the msi server to make any changes to the PC.  However
> the following blog details how to add a manifest to an exe, and one would
> want to set requestExecutionLevel as follows:
> " />"
>
>
> http://blogs.msdn.com/b/willbu/archive/2007/08/23/how-to-embed-a-manifest-to-an-exe-file.aspx?Redirected=true
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-BURN-wpf-and-UAC-promt-tp7587811p7587815.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Versioning on small updates

[Rob Mensching]

Change the 4th field of the version.


On Tue, Aug 6, 2013 at 5:00 PM, Blair Murri  wrote:

> Patching becomes more difficult whenever you change the ProductVersion.
>
> > From: chr...@iswix.com
> > To: wix-users@lists.sourceforge.net; wix-users@lists.sourceforge.net
> > Date: Tue, 6 Aug 2013 14:01:04 -0700
> > Subject: Re: [WiX-users] Versioning on small updates
> >
> > Can someone explain to me the rational behind the definition of a "small
> update"?   My CM background has never liked the though of shipping a new
> MSI that had the same ProductVersion as a previous MSI.  Even if the
> PackageCode GUID is different.  It just doesn't make sense to me.
> >
> > 
> >  From: "David Watson" 
> > Sent: Tuesday, August 06, 2013 10:49 AM
> > To: "General discussion for Windows Installer XML toolset." <
> wix-users@lists.sourceforge.net>
> > Subject: Re: [WiX-users] Versioning on small updates
> >
> > You need to update the file version to allow windows installer to know
> > whether or not to overwrite any existing file.
> >
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa368599(v=vs.85).asp
> > x
> >
> > I don't think the string version is used but I always keep them both in
> sync
> > anyway.
> > Windows installer honours and recognises all four parts of file versions
> (you
> > are correct that it only recognises the first 3 parts of msi product
> > versions).
> >
> > -Original Message-
> > From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com]
> > Sent: 06 August 2013 06:42
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] Versioning on small updates
> >
> > According to the MSDN documentation, small updates are for small fixes
> that
> > don't change the product version. But I can't find definite information
> on
> > what to do with *file* versions. Do I still need to increase the file
> version
> > (in the VERSIONINFO resource) of Win32 PE files that I modify in a small
> > update patch?
> >
> > If yes, is that the numeric FILEVERSION, the string FileVersion, or
> both? And
> > can I bump only the 4th component, or does Windows Installer only take
> the
> > first three into account? (Perhaps I'm mixing things up and that's only
> for
> > MSI product versions, not file versions...)
> >
> > --
> > Nicolás
> >
> >
> -
> > -
> > Get your SQL database under version control now!
> > Version control is standard for application code, but databases havent
> caught
> > up. So what steps can you take to put your SQL databases under version
> > control? Why should you start doing it? Read more to find out.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> > SDL PLC confidential, all rights reserved. If you are not the intended
> recipient of this mail SDL requests and requires that you delete it without
> acting upon or copying any of its contents, and we further request that you
> advise us. SDL PLC is a public limited company registered in England and
> Wales.  Registered number: 02675207. Registered address: Globe House,
> Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK.
> --
> Get your SQL database under version control now! Version control is
> standard for application code, but databases havent caught up. So what
> steps can you take to put your SQL databases under version control? Why
> should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
>  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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> > ___
> > 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _

Re: [WiX-users] [BURN] Install external MSI including a service - solved

[Rob Mensching]

Even better would be to get the MSI fixed. Sounds like there are a couple
issues there. Everything should "Just Work" without forcing anything.


On Wed, Aug 7, 2013 at 2:10 AM, Hendryk Irmischer wrote:

> Yep, ForcePerMachine="yes" did the trick.
>
> First I tried to copy the missing CustomActions from
> InstallExecuteSequence to AdminExecuteSequence. This worked too for me, but
> your solution is clearly the better one.
>
>
>
> Many thanks for the fast response.
>
>
>
> Greetings
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Looking inside of the MSI I would guess that when running the UI it sets
> ALLUSERS to 1 for you, but when you run it in burn (without the MSI's own
> UI) that isn't being set (since the MSI contains conditions/components that
> intend it to be "dual-mode").
>
> I would try adding the ForcePerMachine="yes" attribute to your MsiPackage
> element and see if that fixes it for you.
>
> e.g.
>
> >   Cache="no"  Compressed="yes"
>
> > Permanent="yes"
> Vital="yes" ForcePerMachine="yes"
>
> > Name="$(var.APACHE_MSI)"
>  SourceFile="$(var.APACHE_MSI)" >
>
> Blair
>
> > From: irmisc...@macnetix.de
>
> > To: wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net>
>
> > Date: Mon, 5 Aug 2013 15:11:37 +
>
> > Subject: [WiX-users] [BURN] Install external MSI including a service
>
> >
>
> > Hey folks,
>
> >
>
> > I'm having a problem here. We are currently building an installer for
> our software. But before installing our software, we need to install a web
> server (in our case it's an apache).
>
> > When installing apache via the msi-package (from
> http://mirror.softaculous.com/apache//httpd/binaries/win32/<
> http://mirror.softaculous.com/apache/httpd/binaries/win32/<
> http://mirror.softaculous.com/apache/httpd/binaries/win32/%3chttp:/mirror.softaculous.com/apache/httpd/binaries/win32/>>)
> everything works fine:
>
> >
>
> > -  Apache is being installed
>
> >
>
> > -  Apache service is being installed
>
> >
>
> > -  Apache service is being started
>
> >
>
> > What I want to do now, is to include the apache msi package in our
> installer. Therefore I created a new WiX-Bootstrap Project.
>
> >
>
> > 
> > Version="1.0.0.0"
>
> > Manufacturer="MyCompany"
>
> > UpgradeCode="UPGRADE-GUID-HERE">
>
> >
>
> >  Id="WixStandardBootstrapperApplication.RtfLicense" />
>
> > 
>
> > 
>
> > 
>
> >   
>
> >
>
> > 
>
> > 
>
> >   Cache="no"  Compressed="yes"
>
> > Permanent="yes"
> Vital="yes"
>
> > Name="$(var.APACHE_MSI)"
>  SourceFile="$(var.APACHE_MSI)" >
>
> >  Value="$(var.APACHE_SERVER_ADMIN)" />
>
> >  Value="$(var.APACHE_DOMAIN_NAME)" />
>
> >  Value="$(var.APACHE_HOST_NAME)" />
>
> > 
>
> > 
>
> > 
>
> >
>
> >
>
> > Apache itself installs without errors. But there are 2 steps missing now:
>
> >
>
> > -  The apache service is NOT being installed
>
> >
>
> > -  The apache service is NOT being started
>
> >
>
> > My question now is: What do I have to change to make WiX execute those 2
> final steps (service install and service start) ?
>
> >
>
> >
>
> > Info:
>
> > IDE = VS2008
>
> > OS = Win7
>
> > WiX Version = 3.8
>
> > Minimum Target Environment = WinXP
>
> >
>
> > --
>
> >  Get your SQL database under version control now!
>
> > Version control is standard for application code, but databases havent
>
> > caught up. So what steps can you take to put your SQL databases under
>
> > version control? Why should you start doing it? Read more to find out.
>
> > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.c
>
> > lktrk ___
>
> > 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>
> ___
>
> 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 AppD

Re: [WiX-users] Burn Built-in Variables & Custom Boostrapper UI

[Rob Mensching]

You need to format the string.


On Thu, Aug 8, 2013 at 6:18 AM, Veli-Matti Visuri <
veli-matti.vis...@futuremark.com> wrote:

> Hi, I've been working on a bootstrapper with a customized UI and I cannot
> figure out a way on how to "translate" the burn built-in variables from the
> engine to the UI.
>
> You can see the list of the variables here:
> http://wix.sourceforge.net/manual-wix3/bundle_built_in_variables.htm
>
>
> I'll try to explain the situation here:
> (Before you make remarks, note that this isn't the actual code I'm using)
>
>
> 1. I have a variable defined in the Bundle.wxs like:
>  bal:Overridable="yes"/>
>
>
> 2. I read the variable in the C# customized UI from the engine in the UI
> like this:
> String fooString = Bootstrapper.Engine.StringVariables["FooVariable"];
>
>
> 3. Then I show the install path variable, let's say in a message box
> MessageBox.Show(fooString);
>
>
> 4. The messagebox says:
> [DesktopFolder]\Foo\Bar
>
> But I wish it showed:
> C:\Users\Example\Desktop\Foo\Bar
>
>
> To put it verbally, I would like to make the UI not to say the name of the
> burn built-in variable, but the actual path to the e.g. desktop folder.
>
> Is there any possible way I could do this? Is there any workaround? I
> would't like to programmatically fetch these folders in the UI.
>
> --
> 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn UI Intranet problem

[Rob Mensching]

Sounds like the machine's root certificates are out of date. Burn's call to
verify the payloads will cause Windows to update the root certificates
automatically, if connected.


On Thu, Aug 8, 2013 at 6:41 AM, Adkins, Christopher <
christopher.adk...@docuware.com> wrote:

> Hi everybody!
>
> I was wondering if anyone has any experience with issues using a Custom BA
> on a closed Intranet. When I do this in tests I get the following at the
> end of my log:
>
> [1704:11DC][2013-08-06T15:29:16]: Error 0x800b010a: Failed authenticode
> verification of payload: C:\ProgramData\Package Cache\.unverified\PackageA
> [1704:11DC][2013-08-06T15:29:16]: Error 0x800b010a: Failed to verify
> signature of payload: PackageA
> [1704:11DC][2013-08-06T15:29:16]: Failed to verify payload: PackageA at
> path: C:\ProgramData\Package Cache\.unverified\PackageA, error: 0x800b010a.
> Deleting file.
> [1704:11DC][2013-08-06T15:29:16]: Error 0x800b010a: Failed to cache
> payload: PackageA
> [154C:128C][2013-08-06T15:29:16]: Failed to cache payload: PackageA from
> working path:
> C:\Users\ADMINI~1\AppData\Local\Temp\{afbfaba0-37f6-4750-82d0-0b4641c703be}\PackageA,
> error: 0x800b010a.
> [154C:128C][2013-08-06T15:29:16]: Application requested retry of payload:
> PackageA, encountered error: 0x800b010a. Retrying...
> [154C:128C][2013-08-06T15:29:16]: Prompt for source of package: PackageA,
> payload: PackageA, path:
> C:\Users\Administrator\AppData\Local\Microsoft\Windows\Temporary Internet
> Files\Content.IE5\S9E0SDCR\PackageA.msi
> [154C:128C][2013-08-06T15:29:16]: Acquiring package: PackageA, payload:
> PackageA, download from:
> http://dwserver/DWWebClient/Apps/WebSetup/WebSetupData/PackageA.msi
> [1704:11DC][2013-08-06T15:29:16]: Error 0x800b010a: Failed authenticode
> verification of payload: C:\ProgramData\Package Cache\.unverified\PackageA
> [1704:11DC][2013-08-06T15:29:16]: Error 0x800b010a: Failed to verify
> signature of payload: PackageA
> [1704:11DC][2013-08-06T15:29:16]: Failed to verify payload: PackageA at
> path: C:\ProgramData\Package Cache\.unverified\PackageA, error: 0x800b010a.
> Deleting file.
> [1704:11DC][2013-08-06T15:29:16]: Error 0x800b010a: Failed to cache
> payload: PackageA
> [154C:128C][2013-08-06T15:29:16]: Failed to cache payload: PackageA from
> working path:
> C:\Users\ADMINI~1\AppData\Local\Temp\{afbfaba0-37f6-4750-82d0-0b4641c703be}\PackageA,
> error: 0x800b010a.
> [154C:128C][2013-08-06T15:29:16]: Application requested retry of payload:
> PackageA, encountered error: 0x800b010a. Retrying...
> [154C:128C][2013-08-06T15:29:16]: Prompt for source of package: PackageA,
> payload: PackageA, path:
> C:\Users\Administrator\AppData\Local\Microsoft\Windows\Temporary Internet
> Files\Content.IE5\S9E0SDCR\PackageA.msi
> [154C:128C][2013-08-06T15:29:16]: Acquiring package: PackageA, payload:
> PackageA, download from:
> http://dwserver/DWWebClient/Apps/WebSetup/WebSetupData/PackageA.msi
> [1704:11DC][2013-08-06T15:29:21]: Error 0x800b010a: Failed authenticode
> verification of payload: C:\ProgramData\Package Cache\.unverified\PackageA
> [1704:11DC][2013-08-06T15:29:21]: Error 0x800b010a: Failed to verify
> signature of payload: PackageA
> [1704:11DC][2013-08-06T15:29:21]: Failed to verify payload: PackageA at
> path: C:\ProgramData\Package Cache\.unverified\PackageA, error: 0x800b010a.
> Deleting file.
> [1704:11DC][2013-08-06T15:29:21]: Error 0x800b010a: Failed to cache
> payload: PackageA
> [154C:128C][2013-08-06T15:29:21]: Failed to cache payload: PackageA from
> working path:
> C:\Users\ADMINI~1\AppData\Local\Temp\{afbfaba0-37f6-4750-82d0-0b4641c703be}\PackageA,
> error: 0x800b010a.
> [154C:15E8][2013-08-06T15:29:21]: Error 0x800b010a: Failed while caching,
> aborting execution.
> [1704:156C][2013-08-06T15:29:21]: Removed bundle dependency provider:
> {afbfaba0-37f6-4750-82d0-0b4641c703be}
> [1704:156C][2013-08-06T15:29:21]: Removing cached bundle:
> {afbfaba0-37f6-4750-82d0-0b4641c703be}, from path: C:\ProgramData\Package
> Cache\{afbfaba0-37f6-4750-82d0-0b4641c703be}\
> [1704:156C][2013-08-06T15:29:21]: Unable to remove cached bundle:
> {afbfaba0-37f6-4750-82d0-0b4641c703be}, from path: C:\ProgramData\Package
> Cache\{afbfaba0-37f6-4750-82d0-0b4641c703be}\, reason: 0x80070003.
> Continuing...
> [154C:15E8][2013-08-06T15:29:21]: Apply completed: -2146762486
> [154C:15E8][2013-08-06T15:29:21]: Apply complete, result: 0x800b010a,
> restart: None, ba requested restart:  No
>
> The really strange thing is that if I turn on an active internet
> connection, then the installation works without an issue. If I turn on the
> internet connection, start my installer, cancel it, turn off the internet,
> then run the complete installation, that also works. During this whole
> scenario the Intranet connection is active and working. Any ideas about
> things that I can check for this strange problem would be greatly
> appreciated!
>
> Mit freundlichen Grüßen / Kind Regards,
> Christopher Adkins
> Manager Research and Deve

Re: [WiX-users] Burn and uninstall shortcut

[Rob Mensching]

Not easily supported. The Windows Logo says to not create uninstall
shortcuts so it's not an easily supported scenario in Burn.


On Thu, Aug 8, 2013 at 5:14 AM, Marc Bartsch wrote:

> Hi,
>
> We create an installation .exe with burn that successfully installs .NET4
> as a prerequisite and our .msi which was created with a wix script. All
> this works quite well.
>
> Our wix script creates an uninstall shortcut (pretty much taken from the
> wix how-to pages):
>
>   Name="Uninstall Product Name"
>  Target="[SystemFolder]msiexec.exe"
>   Arguments="/x [ProductCode]"
>   Description="Uninstalls Product" />
>
> If I use this shortcut, the application is correctly uninstalled and all
> relevant files are removed. However, the entry in the  installed programs
> table in "Programs and Feature" is still there. I also notice that it is
> not the burn UI that comes up if I use the uninstall shortcut. Basically,
> my question is: How can I create an uninstall shortcut that removes the
> entry in the Programs and Features table when using burn?
>
> Thanks a lot,
>
> Marc
>
> --
> 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules

[Rob Mensching]

Why not put D2.dll in it's own Component?


On Sun, Aug 11, 2013 at 10:37 PM, Michael Partridge <
michael.partri...@petrosys.com.au> wrote:

> Hi All,
>
> I was wondering if the state of play has changed at all since
> http://stackoverflow.com/questions/703359/wix-add-new-file-to-shared-componentwas
>  discussed?
>
> Basically, I have Product1 (already released) and Product2 (in
> development) which both share the same component A.dll. A.dll is installed
> to %COMMONFILES%/MyProducts/.
>
> Product1 installs A.dll version 1.0.0, which is dependent upon D1.dll.
> Product2 installs A.dll version 1.1.0, which is dependent upon D1.dll and
> D2.dll.
>
> Due to the way that A.dll is used (it's a COM component registered in a
> thirdparty application, and we can only register one .dll) there isn't the
> option of creating newA.dll and putting that into Product2. (At least not
> without breaking Product1.)
>
> I think my only option is to add D2.dll in A.dll's component, breaking the
> component rules, and live with the fact that D2.dll will remain on the
> user's computer if they uninstall Product2 then uninstall Product1. At
> least then, if someone uninstalls Product2 our .dll will continue to run
> correctly.
>
> Does anyone have any further insight?
>
> Thanks,
> Michael
>
> --
> 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Component element and Directory attribute

[Rob Mensching]

Yes, the Component Directory attribute is a reference to the Directory with
matching Id. This pattern is used heavily in the WiX toolset. The Directory
attribute isn't required when the Component element is nested under a
Directory. The doc could be updated to note that a Component's Directory
reference can be inherited from it's parent ComponentGroup Directory
attribute (if present).


On Mon, Aug 12, 2013 at 1:25 AM, Lars Lars  wrote:

> Hello,
>
> First of all, I am new to WIX so be gentle :-) Testing WIX to see if we
> can use it in a project.  Using Wix 3.7 on Windows 7 at the moment.
>
> The script below generate a working msi file but I am not fully sure how
> it works and if it is a sensible setup.
>
> It appears Wix/Product/Feature/ComponentGroupRef refers to
> Wix/Fragment/ComponentGroup which makes sense.
> Then it appears Wix/Fragment/ComponentGroup/Component@Directory contains
> same value as Wix/Product/Directory/Directory/Directory/Directory@Id. Do
> the two attributes form an link between each other?
> If I try to alter the content of either attribute I get 'error LGHT0094:
> Unresolved reference to symbol 'Directory::Dir01' in section 'Fragment:'.
> If I try to remove the Component/@Directory attribute I get "error
> CNDL0010: the Component/@Directory attribute was not found; it is requried".
> If they do form a link, it is not easy to understand based on naming or
> documentation. The documentation for the Component element (
> http://wix.sourceforge.net/manual-wix3/wix_xsd_component.htm) says "Sets
> the Directory of the Component.  If this element is nested under a
> Directory element, this value defaults to the value
> of the parent Directory/@Id. ". The docs should be updated to say this
> attribute is required.
>
> 
> http://schemas.microsoft.com/wix/2006/wi";>
>Language="1033"
> Manufacturer="MyManufacturer"
> Name="MyName"
> UpgradeCode="E5B47089-C70D-46bd-AA9C-D222CFE9A699"
> Version="1.0.0.0">
>
> 
> 
> 
>   
> 
>   
> 
>   
> 
>
> 
>   
> 
>   
>
>   
> 
> Directory="Dir01" Guid="*">
>
>  KeyPath="yes"
>   Source="$(var.SourceDir)\MyFile.ext" />
>   
> 
>   
> 
>
>
>
>
>
> --
> 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Difficulties with Burn (and introducing myself)

[Rob Mensching]

Burn will automatically detect if MSIs are installed. No need to do
anything. Additional help probably requires more detail about what exactly
the searches and conditions were.


On Mon, Aug 12, 2013 at 12:36 PM, Marlos Gottschild <
marlos.gottsch...@gmail.com> wrote:

> Hello,
>
> My name is Marlos and I'm working with WiX for the last 6 months. I'm
> migrating a system from InstallShield to WiX and I'm excited with the
> toolset. I'll be glad to contribute to the list.
>
> But I'm having the following problem with Burn:
>
> I created a bootstrapper to installed two msi packages, let me name them
> pkgA and pkgB. Then I created a RegistrySearch (using UtilExtension) to
> search if pckA is already installed. If so, the pkgA should not be
> installed.
>
> The problem occurs when I try to uninstall the bundle. The pckA gets
> removed even if the bundle didn't install it.
>
> What am I doing wrong?
>
> Thank you.
>
> BR,
> Marlos
>
> --
> 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules

[Rob Mensching]

No, don't force features to not be uninstalled when uninstalling. Crazy
things will happen. In general, don't mess with feature selection lightly.

Michael, I misread the word "dependency". I think you have analyzed the
math on this correctly. This is one of the scenarios where the Component
Rules are fundamentally broken. Windows Installer expected you to not add
dependencies like this... but devs will be devs and it'd be nice if they
actually handled it correctly.




On Tue, Aug 13, 2013 at 2:55 AM, Blair Murri  wrote:

> You could put D2.dll into its own feature, and force that feature to not
> be removed on product removal if product 1 is still installed. You get the
> same "effect" of D2.dll getting orphaned but at least you don't perpetrate
> the problems of sharing binaries in the same component in all other
> scenarios.
>
> > From: michael.partri...@petrosys.com.au
> > To: wix-users@lists.sourceforge.net
> > Date: Tue, 13 Aug 2013 04:07:56 +
> > Subject: Re: [WiX-users] Adding a new dependent file to shared component
> without breaking component rules
> >
> > If I put D2.dll in its own component, then, assuming Product1 and
> Product2 installed, when Product2 is uninstalled, D2.dll will be removed.
> However, A.dll will still be at version 1.1.0, so will have lost its
> dependency and thusly won't run.
> >
> > NB: I can't change Product1 - it's already in the field and won't have
> any updates. In reality Product1 and Product2 are different versions of our
> product that can be installed side-by-side - users like to have access to
> previous versions.
> >
> > Cheers,
> > Michael
> >
> > -Original Message-
> > From: Rob Mensching [mailto:r...@robmensching.com]
> > Sent: Monday, 12 August 2013 6:14 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Adding a new dependent file to shared component
> without breaking component rules
> >
> > Why not put D2.dll in it's own Component?
> >
> >
> > On Sun, Aug 11, 2013 at 10:37 PM, Michael Partridge <
> michael.partri...@petrosys.com.au> wrote:
> >
> > > Hi All,
> > >
> > > I was wondering if the state of play has changed at all since
> > >
> http://stackoverflow.com/questions/703359/wix-add-new-file-to-shared-componentwasdiscussed?
> > >
> > > Basically, I have Product1 (already released) and Product2 (in
> > > development) which both share the same component A.dll. A.dll is
> > > installed to %COMMONFILES%/MyProducts/.
> > >
> > > Product1 installs A.dll version 1.0.0, which is dependent upon D1.dll.
> > > Product2 installs A.dll version 1.1.0, which is dependent upon D1.dll
> > > and D2.dll.
> > >
> > > Due to the way that A.dll is used (it's a COM component registered in
> > > a thirdparty application, and we can only register one .dll) there
> > > isn't the option of creating newA.dll and putting that into Product2.
> > > (At least not without breaking Product1.)
> > >
> > > I think my only option is to add D2.dll in A.dll's component, breaking
> > > the component rules, and live with the fact that D2.dll will remain on
> > > the user's computer if they uninstall Product2 then uninstall
> > > Product1. At least then, if someone uninstalls Product2 our .dll will
> > > continue to run correctly.
> > >
> > > Does anyone have any further insight?
> > >
> > > Thanks,
> > > Michael
> > >
> > > --
> > >  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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.c
> > > lktrk ___
> > > 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 

[WiX-users] [SPAM] Re: multi-language bundle - A BIG THANKS

[Rob Mensching]

PS: The code you are interested in is in
src\ext\BalExtension\wixstdba\WixStandardBootstrapperApplication.cpp,
LoadLocalization(). That uses the helper function LocProbeForFile() that is
in src\dutil\locutil.cpp


On Tue, Aug 13, 2013 at 7:17 AM, TimM  wrote:

> So Phill, did you have a chance to try any of these suggestions and/or WiX
> 3.8 to see if you can get the Burn wrapper .exe to launch correctly in the
> language of the OS?
>
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/My-experiences-making-a-multi-language-bundle-tp7208949p7587976.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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Display value in message - Burn

[Rob Mensching]

"[ServicePackLevel]"?


On Tue, Aug 13, 2013 at 9:57 AM, Christopher M. Bunn <
cmb...@torchmarkcorp.com> wrote:

> Is there a way to display the actual value of ServicePack embedded in the
> message in Burn?  Thanks!
>
>
>
> (VersionNT >= v5.1 AND ServicePackLevel >= 3) OR (VersionNT64 >= v5.1
> AND
> ServicePackLevel >= 3)
>
>
>
> Thanks,
>
> Chris Bunn
>
>
>
>
>
>
> --
> 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [SPAM] Re: Adding .wixlib reference to Wix Install project question

[Rob Mensching]

If you don't reference anything in a Fragment it isn't included in the
final MSI. That's one of the most powerful features of the WiX toolset.


On Fri, Aug 16, 2013 at 8:17 AM, TimM  wrote:

> Quick questions about components within a referenced wixlib.
>
> If you add a new component to a WiX install project .wxs file, but then
> forget to add a reference to that component as part of a ComponentGroup
> and/or Feature then you get an error LGH0267: Found orphaned Component
> 'component Id'. Basically reminding you that you forgot that step and
> therefore a good reminder error that can then be easily corrected.
>
> Now if you add a wixlib reference to a WiX install project and either
> forgot
> to add the ComponentGroup/Component ID or do not know what entries you have
> to add references for in your main .wxs install project and then build your
> project it will NOT give an errors and will complete successfully. So you
> could be adding a bunch of wixlibs that are not actually doing anything as
> long as these references are not added and developers would not even know
> there is a problem.
>
> So my question is why these orphaned components are not captured and errors
> appear in the build when wixlibs are added to install project files and
> references not added?
>
> It would be good to know about these as a new developer may not know what
> references they may need when adding a wixlib and having an error come up
> would help.
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Adding-wixlib-reference-to-Wix-Install-project-question-tp7588106.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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [SPAM] Re: Adding .wixlib reference to Wix Install project question

[Rob Mensching]

Yes. Remember the WiX toolset model is based on C/C++ concepts. In C/C++
you document the functions people can call in your .lib files.


On Fri, Aug 16, 2013 at 8:43 AM, TimM  wrote:

> Okay that makes sence
>
> So do you then just document what components and/or CompoentGroups are in
> your wixlib so that if someone needs to add this wixlib to their project(s)
> that they know what is in it and what they would have to reference to have
> it installed with their project(s)?
>
> I basically just need to know the best way to handle these shared wixlibs
> so
> that new developers know what they would need to do to add a shared wixlib
> to their projects.
>
> Thanks,
>
> Tim.
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Adding-wixlib-reference-to-Wix-Install-project-question-tp7588106p7588108.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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [SPAM] Re: [SPAM] Re: Adding .wixlib reference to Wix Install project question

[Rob Mensching]

I agree. That would be a pretty cool feature. VC++ doesn't provide it but
it'd be cool for .lib files as well.


On Fri, Aug 16, 2013 at 8:50 AM, TimM  wrote:

> Yes Rob that is true with added fragments, but with the fragments as long
> as
> they are part of your project you can see the components listed and
> therefore reference the ones you want, where as a wixlib you can see the
> reference in your project, but you can not see the components within it and
> therefore would not know what components you can reference. So it would be
> a
> great to update this so that if you open up the wixlib referenced that it
> would show what is in it so that you can then see the components and
> therefore can create the references that you need.
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Adding-wixlib-reference-to-Wix-Install-project-question-tp7588106p7588112.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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [SPAM] Re: set Features depending other

[Rob Mensching]

Be very, very careful using ADDLOCAL and friends directly on the
command-line. You can really get confused behavior in the MSI if you get
that wrong. You'll want to test lots and lots of scenarios (install,
uninstall, patch, repair upgrade) with all the different permutations.


On Mon, Aug 19, 2013 at 6:49 AM, Phill Hogland  wrote:

> I know that there are a number of different approaches that one might take
> to
> address this question.  One approach might be to use something similar to
> Example #11, at:
> http://wixextba.codeplex.com/releases/view/105895
>
> Which involves a bundle that displays radio buttons and then use that
> exclusive or output, with the ADDLOCAL (or one of the other MSI properties
> used to select Features), to configure the chained MsiPackage.
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/set-Features-depending-other-tp7588144p7588178.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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ExePackage/@DetectCondition syntax

[Rob Mensching]

You want DetectCondition.  InstallCondition says whether a package should
be installed on the machine. If false and the package is installed, it will
uninstall the package.


On Mon, Aug 19, 2013 at 7:21 AM, Kenneth Porter wrote:

> --On Monday, August 19, 2013 8:01 AM -0700 Phill Hogland
>  wrote:
>
> > It seems like you would want to use DetectCondition to determine if the
> > package already exists and InstallCondition to determine when you want to
> > launch the exe.
>
> If the prerequisite package is not installed, I want to run its installer.
> If it's installed, I want to skip that.
>
>
>
>
> --
> 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [SPAM] Re: .NET Framework Install

[Rob Mensching]

WiX toolset install does.


On Mon, Aug 19, 2013 at 11:26 AM, yugolancer  wrote:

> Hi Guys,
>
> Would you show me an example of bootstrapper which simply checks on start
> if
> .NET 4.0 is installed and install if not and THEN just start my regular
> setup AS IS without installing it in background.
>
> Currently it does install the SETUP silently so the user cannot interact
> with it which is very important (selecting options and stuff)
>
> Thanks
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/NET-Framework-Install-tp7588206.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] disassemble a bundle

[Rob Mensching]

Just like everything else: dark.exe.


On Mon, Aug 19, 2013 at 11:44 AM, jo...@msli.com  wrote:

> Is there a way to disassemble a bundle?
>
>
>
> NOTICE: This email may contain confidential information.  Please see
> http://www.meyersound.com/confidential/ for our complete policy.
>
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Selecting which Features to include from wixlib

[Rob Mensching]

An entire Fragment is included when referenced.


On Mon, Aug 19, 2013 at 12:15 PM, Marlos Gottschild <
marlos.gottsch...@gmail.com> wrote:

> Hi,
>
> I have a wixlib with Components, ComponentGroups and Features and another
> wix project referencing this library. And I need to selectively choose
> which Features from the wixlib I will include in my main setup. This way:
>
> wixlib:
> file1.wxs
> 
>   
> 
>   
> 
>   
>   
> 
>   
> 
>   
> 
> file2.wxs
> 
>Description="My feature A">
> 
>   
>Description="My feature B">
> 
>   
> 
>
> And my main setup:
> 
> ...
>   
>   
> 
>
> The problem is that when I try to install, both features (and
> components/files) get installed.
>
> I'm definitely doing something wrong, but don't know what to do to correct
> this. Any help?
>
> Thank you in advance.
>
> BR,
> Marlos
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Selecting which Features to include from wixlib

[Rob Mensching]

Don't have to be in separate files.


On Mon, Aug 19, 2013 at 12:44 PM, Marlos Gottschild <
marlos.gottsch...@gmail.com> wrote:

> Works like a charm. Thanks Rob and Philippe.
>
> For future reference, I moved both ComponentGroup and Feature to a separate
> file, not only ComponentGroup.
>
> Thanks again.
> BR,
> Marlos
>
>
>
> 2013/8/19 Rob Mensching 
>
> > An entire Fragment is included when referenced.
> >
> >
> > On Mon, Aug 19, 2013 at 12:15 PM, Marlos Gottschild <
> > marlos.gottsch...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I have a wixlib with Components, ComponentGroups and Features and
> another
> > > wix project referencing this library. And I need to selectively choose
> > > which Features from the wixlib I will include in my main setup. This
> way:
> > >
> > > wixlib:
> > > file1.wxs
> > > 
> > >   
> > > 
> > >   
> > > 
> > >   
> > >   
> > > 
> > >   
> > > 
> > >   
> > > 
> > > file2.wxs
> > > 
> > >> > Description="My feature A">
> > > 
> > >   
> > >> > Description="My feature B">
> > > 
> > >   
> > > 
> > >
> > > And my main setup:
> > > 
> > > ...
> > >   
> > >   
> > > 
> > >
> > > The problem is that when I try to install, both features (and
> > > components/files) get installed.
> > >
> > > I'm definitely doing something wrong, but don't know what to do to
> > correct
> > > this. Any help?
> > >
> > > Thank you in advance.
> > >
> > > BR,
> > > Marlos
> > >
> > >
> >
> --
> > > Introducing Performance Central, a new site from SourceForge and
> > > AppDynamics. Performance Central is your source for news, insights,
> > > analysis and resources for efficient Application Performance
> Management.
> > > Visit us today!
> > >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> > > ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> > >
> >
> >
> --
> > Introducing Performance Central, a new site from SourceForge and
> > AppDynamics. Performance Central is your source for news, insights,
> > analysis and resources for efficient Application Performance Management.
> > Visit us today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] bundle error if I build though automated system

[Rob Mensching]

Did you sign the bundle according to the documentation on the Insignia page?


On Mon, Aug 19, 2013 at 4:57 PM, jo...@msli.com  wrote:

> I sign the bundle I get this error.
> An unsigned bundle seems to work.
>
> On Mon, 2013-08-19 at 15:36 -0700, jo...@msli.com wrote:
> > Looks like my log file was stripped out
> >
> > [0EA8:0208][2013-08-19T14:44:54]i001: Burn v3.7.1224.0, Windows v6.1
> (Build 7601: Service Pack 1), path:
> C:\Users\build\Desktop\MyProgram-3.1.0-3776-Installer.exe, cmdline:
> '-burn.unelevated BurnPipe.{A7261C75-BACC-4401-B5F3-42EEC22098B5}
> {F94F9B48-9AB8-4C18-969A-9AAF3E9BB205} 3852'
> > [0EA8:0208][2013-08-19T14:44:54]i000: Setting string variable
> 'WixBundleLog' to value
> 'C:\Users\build\AppData\Local\Temp\My_Company_MyProgram_3.1.0_Bundle_20130819144454.log'
> > [0EA8:0208][2013-08-19T14:44:54]i000: Setting string variable
> 'WixBundleOriginalSource' to value
> 'C:\Users\build\Desktop\MyProgram-3.1.0-3776-Installer.exe'
> > [0EA8:0208][2013-08-19T14:44:55]i052: Condition '( (VersionNT >= v5.1)
> AND (ServicePackLevel >= 3)) OR ( (VersionNT >= v5.2) AND (ServicePackLevel
> >= 2)) OR (VersionNT >= v6.0)' evaluates to true.
> > [0EA8:0208][2013-08-19T14:44:55]i000: Setting string variable
> 'WixBundleName' to value 'Meyer Sound MyProgram 3.1.0 Bundle'
> > [0EA8:0208][2013-08-19T14:44:55]i100: Detect begin, 4 packages
> > [0EA8:0208][2013-08-19T14:44:55]i000: Setting numeric variable
> 'BonjourDLL' to value 1
> > [0EA8:0208][2013-08-19T14:44:55]i000: Setting string variable
> 'BounjourVersion' to value '2.0.2.0'
> > [0EA8:0208][2013-08-19T14:44:55]i000: Setting numeric variable
> 'ProxyInstalled' to value 1
> > [0EA8:0208][2013-08-19T14:44:55]i000: Setting numeric variable
> 'WinPcapInstalled' to value 1
> > [0EA8:0208][2013-08-19T14:44:55]i000: Setting string variable
> 'WinPcapVersionMajor' to value '4'
> > [0EA8:0208][2013-08-19T14:44:55]i000: Setting string variable
> 'WinPcapVersionMinor' to value '1'
> > [0EA8:0208][2013-08-19T14:44:55]i103: Detected related package:
> {03D789F3-42D5-4FEC-BCDA-0F5BAC51B535}, scope: PerMachine, version:
> 1.0.3.0, language: 0 operation: Downgrade
> > [0EA8:0208][2013-08-19T14:44:55]i101: Detected package: WinPcap, state:
> Absent, cached: None
> > [0EA8:0208][2013-08-19T14:44:55]i101: Detected package: BonjourPSSetup,
> state: Absent, cached: None
> > [0EA8:0208][2013-08-19T14:44:55]i101: Detected package: MyProxy, state:
> Obsolete, cached: None
> > [0EA8:0208][2013-08-19T14:44:55]i104: Detected package: MyProxy,
> feature: DefaultFeature, state: Absent
> > [0EA8:0208][2013-08-19T14:44:55]i101: Detected package:
> MyProgramInstaller, state: Absent, cached: None
> > [0EA8:0208][2013-08-19T14:44:55]i104: Detected package:
> MyProgramInstaller, feature: Complete, state: Absent
> > [0EA8:0208][2013-08-19T14:44:55]i199: Detect complete, result: 0x0
> > [0EA8:0208][2013-08-19T14:44:59]i200: Plan begin, 4 packages, action:
> Install
> > [0EA8:0208][2013-08-19T14:44:59]i052: Condition 'NOT WinPcapInstalled OR
> ( 4 > WinPcapVersionMajor AND 1 > WinPcapVersionMinor)' evaluates to false.
> > [0EA8:0208][2013-08-19T14:44:59]w321: Skipping dependency registration
> on package with no dependency providers: WinPcap
> > [0EA8:0208][2013-08-19T14:44:59]i052: Condition 'NOT BonjourDLL OR
> v2.0.2.0 > BonjourVersion' evaluates to false.
> > [0EA8:0208][2013-08-19T14:44:59]w321: Skipping dependency registration
> on package with no dependency providers: BonjourPSSetup
> > [0EA8:0208][2013-08-19T14:44:59]i204: Plan 1 msi features for package:
> MyProgramInstaller
> > [0EA8:0208][2013-08-19T14:44:59]i203: Planned feature: Complete, state:
> Absent, default requested: Unknown, ba requested: Unknown, execute action:
> None, rollback action: None
> > [0EA8:0208][2013-08-19T14:44:59]i000: Setting string variable
> 'WixBundleRollbackLog_MyProgramInstaller' to value
> 'C:\Users\build\AppData\Local\Temp\My_Company_MyProgram_3.1.0_Bundle_20130819144454_0_MyProgramInstaller_rollback.log'
> > [0EA8:0208][2013-08-19T14:44:59]i000: Setting string variable
> 'WixBundleLog_MyProgramInstaller' to value
> 'C:\Users\build\AppData\Local\Temp\My_Company_MyProgram_3.1.0_Bundle_20130819144454_0_MyProgramInstaller.log'
> > [0EA8:0208][2013-08-19T14:44:59]i201: Planned package: WinPcap, state:
> Absent, default requested: Absent, ba requested: Absent, execute: None,
> rollback: None, cache: No, uncache: No, dependency: None
> > [0EA8:0208][2013-08-19T14:44:59]i201: Planned package: BonjourPSSetup,
> state: Absent, default requested: Absent, ba requested: Absent, execute:
> None, rollback: None, cache: No, uncache: No, dependency: None
> > [0EA8:0208][2013-08-19T14:44:59]i201: Planned package: MyProxy, state:
> Obsolete, default requested: None, ba requested: None, execute: None,
> rollback: None, cache: No, uncache: No, dependency: None
> > [0EA8:0208][2013-08-19T14:44:59]i201: Planned package:
> MyProgramInstaller, state: Absent, default requested: Present, ba
> requested: Present, ex

[WiX-users] New Bug and Feature Request location: http://wixtoolset.org/issues/

[Rob Mensching]

WiX Toolset Bugs and Features are now found here: http://wixtoolset.org/issues/

Today we launched the new WiX toolset issue tracker at 
http://wixtoolset.org/issues/. A lot of the technology is brand new and there 
will ongoing improvements. The important thing is that we can now make 
improvements where we were at the whim of SourceForge with issues with the old 
issue tracker.

All issues have been migrated but some things could not come across (for 
example, ownership and attachments were not fully migrated). If you find 
problems with issues migrated or have problems using the new issue tracker, 
please contact me so we can sort out any problems. As noted above, a lot of 
this is new technology so please be patient as we work out a few kinks and add 
more functionality.

In the meantime, keep coding. You know I am! 

virtually,

   Rob Mensching
   Your Friendly Neighborhood Benevolent Dictator
   WiX Toolset

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Embedded UI Dependent files

[Rob Mensching]

Online documentation should be back again. There is also always the wix.chm
that is installed with the WiX toolset.


On Wed, Aug 21, 2013 at 8:15 AM, Steven Ogilvie wrote:

> Is this for Burn, wouldn't you use Payload
> i.e. 
>
> Steve
>
> -Original Message-
> From: Phyx [mailto:loneti...@gmail.com]
> Sent: August-21-13 11:06 AM
> To: wix-users@lists.sourceforge.net
> Cc: loneti...@gmail.com
> Subject: [WiX-users] Embedded UI Dependent files
>
> Hi Guys,
>
> I have finally gotten an Embedded WPF example to work, but I've ran into a
> problem: I need to add some extra files that should only be used by the WPF
> UI.
>
> without these the UI doesn't run. The problem is I don't know how to add
> them. If I use a   wouldn't that be added as a part of
> the installed application instead of the UI installer?
>
> I have been trying to look at the documentation but it's been down all day
> unfortunately.
>
> I'm sure i'm missing something quite simple.
>
> Regards,
> Tamar
>
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] disassemble a bundle

[Rob Mensching]

Sorry, you probably got caught in the middle of the migration.
http://wixtoolset.org/bugs/ link should work correctly now.


On Tue, Aug 20, 2013 at 8:48 PM, Blair Murri  wrote:

> Once you have the bug tracker up on sourceforge, you need to login using a
> sourceforge account.
>
> > From: jo...@msli.com
> > To: wix-users@lists.sourceforge.net
> > Date: Tue, 20 Aug 2013 17:24:59 -0700
> > Subject: Re: [WiX-users] disassemble a bundle
> >
> > How do I file a bug?
> >
> > I get "Oops, looks like something went wrong." no matter how I try to
> > reach your bug tracking system.
> >
> > >From http://wixtoolset.org
> >  I click 'Bugs', which points to  http://wixtoolset.org/bugs
> >
> > >From http://wix.sourceforge.net/ On the right under Support -> Bug
> > Database also points to http://wixtoolset.org/bugs
> >
> > I also tried to reach: http://sourceforge.net/p/wix/bugs/
> >
> > >From https://sourceforge.net/projects/wix/
> > I clicked on Tickets -> Bugs
> >
> > What is the correct way?
> >
> > On Mon, 2013-08-19 at 22:36 -0700, Blair Murri wrote:
> > > I think we should make that error message more clear. Please file a
> bug.
> > >
> > > > From: jo...@msli.com
> > > > To: wix-users@lists.sourceforge.net
> > > > Date: Mon, 19 Aug 2013 14:00:08 -0700
> > > > Subject: Re: [WiX-users] disassemble a bundle
> > > >
> > > > I see I had to make a directory and extract into it
> > > > dark.exe -x foo MyProgram-3.1.0-3776-Installer.exe
> > > >
> > > > On Mon, 2013-08-19 at 13:52 -0700, jo...@msli.com wrote:
> > > > > I ask because dark didn't work for me.
> > > > >
> > > > > $ dark  MyProgram-3.1.0-3776-Installer.exe
> > > > > Windows Installer Xml Decompiler version 3.7.1224.0
> > > > > Copyright (C) Outercurve Foundation. All rights reserved.
> > > > >
> > > > > MyProgram-3.1.0-3776-Installer.exe
> > > > > dark.exe : error DARK0001 : Value cannot be null.
> > > > > Parameter name: path1
> > > > >
> > > > > Exception Type: System.ArgumentNullException
> > > > >
> > > > > Stack Trace:
> > > > >at System.IO.Path.Combine(String path1, String path2)
> > > > >at
> Microsoft.Tools.WindowsInstallerXml.Unbinder.UnbindBundle(String
> > > > > bundleFile, String exportBasePath)
> > > > >at Microsoft.Tools.WindowsInstallerXml.Unbinder.Unbind(String
> file,
> > > > > OutputType outputType, String exportBasePath)
> > > > >at Microsoft.Tools.WindowsInstallerXml.Tools.Dark.Run(String[]
> args)
> > > > >
> > > > >
> > > > > On Mon, 2013-08-19 at 11:55 -0700, Rob Mensching wrote:
> > > > > > Just like everything else: dark.exe.
> > > > > >
> > > > > >
> > > > > > On Mon, Aug 19, 2013 at 11:44 AM, jo...@msli.com 
> wrote:
> > > > > >
> > > > > > > Is there a way to disassemble a bundle?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > NOTICE: This email may contain confidential information.
>  Please see
> > > > > > > http://www.meyersound.com/confidential/ for our complete
> policy.
> > > > > > >
> > > > > > >
> > > > > > >
> --
> > > > > > > Introducing Performance Central, a new site from SourceForge
> and
> > > > > > > AppDynamics. Performance Central is your source for news,
> insights,
> > > > > > > analysis and resources for efficient Application Performance
> Management.
> > > > > > > Visit us today!
> > > > > > >
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> > > > > > > ___
> > > > > > > WiX-users mailing list
> > > > > > > WiX-users@lists.sourceforge.net
> > > > > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > > > > > >
> > > > > > >
> > > > > >
> -

Re: [WiX-users] Expected behaviour

[Rob Mensching]

Bob wrote a nice blog entry about this:
http://www.joyofsetup.com/2008/12/30/paying-for-upgrades/

Lots of tradeoffs to consider.


On Wed, Aug 21, 2013 at 1:33 PM,  wrote:

> Thank you for the information, Phil. This raises another bunch of
> questions:
>
> Why is the default in this location in the sequence (that seems
> unfortunate, since rollbacks are part of the point of using MSIs)?
> Should I change the location for all my installers?
> What's a good way to this when building the package? If I change nothing
> but add an InstallExecuteSequenceElement with a RemoveExistingProducts with
> a Sequence attribute of, say, 1501, will I be ok?
> Or do I have to use a complete other sequence (i.e., fill in all the
> values for all the other steps which might occur "manually")?
>
> (I looked at Nick Ramirez's book for 3.0, and this doesn't seem to be
> covered.)
>
>
> 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: Phil Wilson [mailto:phildgwil...@gmail.com]
> Sent: August-21-13 4:02 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Expected behaviour
>
> When REP is at that location, it's essentially a complete uninstall of the
> older product followed by the install of the new product, so what you get
> is very similar to a user uninstall of the old product and then the install
> of the new. The older files will be installed because you're basically
> doing a fresh install of the new product containing older files. Other
> locations of REP aren't all like that.
>
> Your problem is that REP needs to be after InstallInitialize because the
> rollback transation boundaries are InstallInitialize and InstallFinalize,
> so your REP was not in the transaction and not rolled back.
>
>
>
>
>
> Phil Wilson
>
>
> On Wed, Aug 21, 2013 at 12:04 PM,  wrote:
>
> > Thanks for answering Phil,
> >
> > Unfortunately a verbose log is not available. However, I know that
> > there's no explicit sequencing of RemoveExistingProducts or anything
> > else for that matter by my WXS. According to the MSI itself it is
> > 1401, immediately after InstallValidate and before InstallInitialize
> > (I assume the sequence is just in ascending order of Sequence in the
> > InstallExecuteSequence table.)
> >
> > (If it matters, the whole is
> > FindRelatedProducts,AppSearch,LaunchConditions,ValiadateProductID,Cost
> > Initialize,FileCost,CostFinalize,MigrateFeatureStates,InstallValidate,
> > RemoveExistingProducts,InstallInitialize,ProcessComponents,UnpublishFe
> > atures,StopServices,DeleteServices,RemoveFiles,InstallFiles,InstallSer
> > vices,StartServices,RegisterUser,RegisterProduct,PublishFeatures,Publi
> > shProduct,InstallFinalize.)
> >
> >
> > 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: Phil Wilson [mailto:phildgwil...@gmail.com]
> > Sent: August-21-13 2:43 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Expected behaviour
> >
> > A proper answer will depend on where you have sequenced
> > RemoveExistingProducts.
> >
> > A verbose log will tell you what happened.
> >
> > Phil Wilson
> >
> >
> > On Wed, Aug 21, 2013 at 10:25 AM,  wrote:
> >
> > > If a service update (a MajorUpgrade of a service installation) fails
> > > for some reason, and a rollback to the previous version happens,
> > > what happens if the MSI for the rollback cannot be found? Would this
> > > leave no files from the first package in the installation directory?
> > > I guess I may have naïvely thought that the rollback would just use
> > > the directory as is. If that's the case, what caches a copy of MSIs
> > > in the system directory so we can use them in this situation? We'd
> > > like to keep a sensibly named version in our own installer directory
> > > on these machines so technicians can do the installation manually
> > > under certain circumstances and to interoperate with our file
> > > transfer mechanism
> > (details of no importances).
> > >
> > > I'm trying to figure out why an install of one of our services had
> > > the net effect of simply deleting the old files but repair (of the
> > > seemingly installed new package) restored the new ones. All I know
> > > is accidentally old versions of the executable and libraries were
> > > included
> > in the new MSI.
> > >
> > > Moreover, what is supposed to happen in general in a MajorUpgrade if
> > > the KeyP

Re: [WiX-users] New Bug and Feature Request location: http://wixtoolset.org/issues/

[Rob Mensching]

I didn't know it looked *that* bad. I thought Bootstrap handled IE8 better.
I'll read up about it a bit and see if it can at least be somewhat useful
in IE8 and 9.


On Wed, Aug 21, 2013 at 2:11 PM, Neil Sleightholm wrote:

> I know it is old but did you know that the page doesn't display properly
> in IE8?
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: 21 August 2013 08:25
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] New Bug and Feature Request location:
> http://wixtoolset.org/issues/
>
> WiX Toolset Bugs and Features are now found here:
> http://wixtoolset.org/issues/
>
> Today we launched the new WiX toolset issue tracker at
> http://wixtoolset.org/issues/. A lot of the technology is brand new and
> there will ongoing improvements. The important thing is that we can now
> make improvements where we were at the whim of SourceForge with issues with
> the old issue tracker.
>
> All issues have been migrated but some things could not come across (for
> example, ownership and attachments were not fully migrated). If you find
> problems with issues migrated or have problems using the new issue tracker,
> please contact me so we can sort out any problems. As noted above, a lot of
> this is new technology so please be patient as we work out a few kinks and
> add more functionality.
>
> In the meantime, keep coding. You know I am! 
>
> virtually,
>
>Rob Mensching
>Your Friendly Neighborhood Benevolent Dictator
>WiX Toolset
>
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] New Bug and Feature Request location: http://wixtoolset.org/issues/

[Rob Mensching]

Fixed. Somehow the search results page lost it's HTML5 doctype causing the
older browsers to go into quirks mode. I fixed the doctype and it should be
rendering better in IE7+.

Thanks for the heads up.


On Wed, Aug 21, 2013 at 2:30 PM, Rob Mensching  wrote:

> I didn't know it looked *that* bad. I thought Bootstrap handled IE8
> better. I'll read up about it a bit and see if it can at least be somewhat
> useful in IE8 and 9.
>
>
> On Wed, Aug 21, 2013 at 2:11 PM, Neil Sleightholm wrote:
>
>> I know it is old but did you know that the page doesn't display properly
>> in IE8?
>>
>> -Original Message-
>> From: Rob Mensching [mailto:r...@robmensching.com]
>> Sent: 21 August 2013 08:25
>> To: wix-users@lists.sourceforge.net
>> Subject: [WiX-users] New Bug and Feature Request location:
>> http://wixtoolset.org/issues/
>>
>> WiX Toolset Bugs and Features are now found here:
>> http://wixtoolset.org/issues/
>>
>> Today we launched the new WiX toolset issue tracker at
>> http://wixtoolset.org/issues/. A lot of the technology is brand new and
>> there will ongoing improvements. The important thing is that we can now
>> make improvements where we were at the whim of SourceForge with issues with
>> the old issue tracker.
>>
>> All issues have been migrated but some things could not come across (for
>> example, ownership and attachments were not fully migrated). If you find
>> problems with issues migrated or have problems using the new issue tracker,
>> please contact me so we can sort out any problems. As noted above, a lot of
>> this is new technology so please be patient as we work out a few kinks and
>> add more functionality.
>>
>> In the meantime, keep coding. You know I am! 
>>
>> virtually,
>>
>>Rob Mensching
>>Your Friendly Neighborhood Benevolent Dictator
>>WiX Toolset
>>
>>
>> --
>> Introducing Performance Central, a new site from SourceForge and
>> AppDynamics. Performance Central is your source for news, insights,
>> analysis and resources for efficient Application Performance Management.
>> Visit us today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>>
>> --
>> Introducing Performance Central, a new site from SourceForge and
>> AppDynamics. Performance Central is your source for news, insights,
>> analysis and resources for efficient Application Performance Management.
>> Visit us today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>>
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] New Bug and Feature Request location: http://wixtoolset.org/issues/

[Rob Mensching]

Yes. It looks funny now but will make much more sense after Triage opens a
bunch of the bugs. Issue Workflow is a topic for the WiX Online Meeting
later today.


On Thu, Aug 22, 2013 at 12:20 AM, Neil Sleightholm wrote:

> Works ok now, thanks.
>
> Is it right that by default when you go to the site no bugs are shown, you
> have to click Untriaged to see any thing?
>
> Neil
> ____
> From: Rob Mensching [r...@robmensching.com]
> Sent: 21 August 2013 23:09
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] New Bug and Feature Request location:
> http://wixtoolset.org/issues/
>
> Fixed. Somehow the search results page lost it's HTML5 doctype causing the
> older browsers to go into quirks mode. I fixed the doctype and it should be
> rendering better in IE7+.
>
> Thanks for the heads up.
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Embedded UI Dependent files (Steven Ogilvie)

[Rob Mensching]

With Burn that is not the approach I would take. A bit of my opinion here:
http://robmensching.com/blog/posts/2012/6/25/b-is-for-bundle-and-thats-good-enough-for-me

You are, of course, entitled to your own opinion of the best approach.



On Thu, Aug 22, 2013 at 12:40 AM, Phyx  wrote:

> Hi Steve,
>
> No I'm not using Burn yet, since I figured on my test machines I already
> have .net installed so I can wait to get the bootloader done. I thought the
> individual .msi's should be self contained. e.g modulo the dependencies
> they should have all the resources they need to run right? Like if I had an
> image I wanted to display in the installer UI, that should be a part of the
> .msi and not burn right?
>
>
> Cheers,
> Tamar
>
> > -- Forwarded message --
> > From: Steven Ogilvie 
> > To: General discussion for Windows Installer XML toolset. <
> > wix-users@lists.sourceforge.net>
> > Cc:
> > Date: Wed, 21 Aug 2013 15:15:47 +
> > Subject: Re: [WiX-users] Embedded UI Dependent files
> > Is this for Burn, wouldn't you use Payload
> > i.e. 
> >
> > Steve
> >
> > -Original Message-
> > From: Phyx [mailto:loneti...@gmail.com]
> > Sent: August-21-13 11:06 AM
> > To: wix-users@lists.sourceforge.net
> > Cc: loneti...@gmail.com
> > Subject: [WiX-users] Embedded UI Dependent files
> >
> > Hi Guys,
> >
> > I have finally gotten an Embedded WPF example to work, but I've ran into
> a
> > problem: I need to add some extra files that should only be used by the
> WPF
> > UI.
> >
> > without these the UI doesn't run. The problem is I don't know how to add
> > them. If I use a   wouldn't that be added as a part
> of
> > the installed application instead of the UI installer?
> >
> > I have been trying to look at the documentation but it's been down all
> day
> > unfortunately.
> >
> > I'm sure i'm missing something quite simple.
> >
> > Regards,
> > Tamar
> >
> >
> >
> --
> > Introducing Performance Central, a new site from SourceForge and
> > AppDynamics. Performance Central is your source for news, insights,
> > analysis and resources for efficient Application Performance Management.
> > Visit us today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] New Bug and Feature Request location: http://wixtoolset.org/issues/

[Rob Mensching]

You login only when you have to. The site will let you know. 

User editing is open issue #5 (https://github.com/robmen/tinybugs/issues/5).
On my list...




On Thu, Aug 22, 2013 at 10:11 AM, Neil Sleightholm wrote:

> When you go to the issue site there doesn't seem to be a way to login, am
> I missing something?
>
> Also, I created my account without an alias so not my email address is
> display - can I edit my account?
>
> Neil
>
> -----Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: 21 August 2013 08:25
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] New Bug and Feature Request location:
> http://wixtoolset.org/issues/
>
> WiX Toolset Bugs and Features are now found here:
> http://wixtoolset.org/issues/
>
> Today we launched the new WiX toolset issue tracker at
> http://wixtoolset.org/issues/. A lot of the technology is brand new and
> there will ongoing improvements. The important thing is that we can now
> make improvements where we were at the whim of SourceForge with issues with
> the old issue tracker.
>
> All issues have been migrated but some things could not come across (for
> example, ownership and attachments were not fully migrated). If you find
> problems with issues migrated or have problems using the new issue tracker,
> please contact me so we can sort out any problems. As noted above, a lot of
> this is new technology so please be patient as we work out a few kinks and
> add more functionality.
>
> In the meantime, keep coding. You know I am! 
>
> virtually,
>
>Rob Mensching
>Your Friendly Neighborhood Benevolent Dictator
>WiX Toolset
>
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [SPAM] Re: New Bug and Feature Request location: http://wixtoolset.org/issues/

[Rob Mensching]

Yeah, the error cases around accounts that are not yet verified are not
great. Another area to improve.


On Thu, Aug 22, 2013 at 1:29 PM, Neil Sleightholm wrote:

> Did you get the activation email? (Mine went to the Junkmail.)
>
> -Original Message-
> From: Phill Hogland [mailto:phogl...@rimage.com]
> Sent: 22 August 2013 20:45
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] New Bug and Feature Request location:
> http://wixtoolset.org/issues/
>
> It prompted me for a login (or create an account) and I created a login
> and logged in successfully.  I then tried to create a bug and it prompted
> for a login and would not accept the credentials created a few seconds
> earlier.
> (So I will just keep track of the issue until I learn how to file a bug.)
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/New-Bug-and-Feature-Request-location-http-wixtoolset-org-issues-tp7588281p7588350.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] New Bug and Feature Request location: http://wixtoolset.org/issues/

[Rob Mensching]

Ahh, yes. That may be a bug.


On Thu, Aug 22, 2013 at 12:28 PM, Neil Sleightholm wrote:

> Ah, in that case it needs to "know" that when I click "My Open" I need to
> logon.
>
> Neil
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: 22 August 2013 18:51
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] New Bug and Feature Request location:
> http://wixtoolset.org/issues/
>
> You login only when you have to. The site will let you know. 
>
> User editing is open issue #5 (https://github.com/robmen/tinybugs/issues/5
> ).
> On my list...
>
>
>
>
> On Thu, Aug 22, 2013 at 10:11 AM, Neil Sleightholm  >wrote:
>
> > When you go to the issue site there doesn't seem to be a way to login,
> > am I missing something?
> >
> > Also, I created my account without an alias so not my email address is
> > display - can I edit my account?
> >
> > Neil
> >
> > -Original Message-
> > From: Rob Mensching [mailto:r...@robmensching.com]
> > Sent: 21 August 2013 08:25
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] New Bug and Feature Request location:
> > http://wixtoolset.org/issues/
> >
> > WiX Toolset Bugs and Features are now found here:
> > http://wixtoolset.org/issues/
> >
> > Today we launched the new WiX toolset issue tracker at
> > http://wixtoolset.org/issues/. A lot of the technology is brand new
> > and there will ongoing improvements. The important thing is that we
> > can now make improvements where we were at the whim of SourceForge
> > with issues with the old issue tracker.
> >
> > All issues have been migrated but some things could not come across
> > (for example, ownership and attachments were not fully migrated). If
> > you find problems with issues migrated or have problems using the new
> > issue tracker, please contact me so we can sort out any problems. As
> > noted above, a lot of this is new technology so please be patient as
> > we work out a few kinks and add more functionality.
> >
> > In the meantime, keep coding. You know I am! 
> >
> > virtually,
> >
> >Rob Mensching
> >Your Friendly Neighborhood Benevolent Dictator
> >WiX Toolset
> >
> >
> > --
> >  Introducing Performance Central, a new site from SourceForge
> > and AppDynamics. Performance Central is your source for news,
> > insights, analysis and resources for efficient Application Performance
> > Management.
> > Visit us today!
> > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.c
> > lktrk ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> > --
> >  Introducing Performance Central, a new site from SourceForge
> > and AppDynamics. Performance Central is your source for news,
> > insights, analysis and resources for efficient Application Performance
> > Management.
> > Visit us today!
> > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.c
> > lktrk ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-us

Re: [WiX-users] Burn uninstalls product instead of upgrading it

[Rob Mensching]

Might be related to: http://wixtoolset.org/issues/3643/


On Fri, Aug 23, 2013 at 3:24 AM, Bruce Cran  wrote:

> I seem to have managed to get Burn rather confused. I have an MSI
> package with new product and upgrade codes in version 2.0 due to
> different builds being produced. I ask Windows Installer (in the MSI) to
> upgrade from the previous one with:
> Snippet
>
> 
> Maximum="1.9.9" IncludeMinimum="yes" IncludeMaximum="yes"/>
> 
>
> 
> Property="THIS_PRODUCT_INSTALLED" OnlyDetect="yes"/>
> 
> 
> Property="OTHER_PRODUCT_INSTALLED" OnlyDetect="yes"/>
> 
>
> 
> 
>NOT OTHER_PRODUCT_INSTALLED
> 
>
> However, when I run the installer, Burn logs:
>
> Detected related bundle: {BUNDLE_GUID}, type: Upgrade, scope:
> PerMachine, version: 1.0.0, operation: MajorUpgrade
> Detected related package: {OLD_PRODUCT_CODE}, scope: PerMachine,
> version: 1.0.0, language: 0 operation: MajorUpgrade
> Detected related package: {OLD_PRODUCT_CODE}, scope: PerMachine,
> version: 1.0.0, language: 0 operation: Downgrade
> Detected package: Product.msi, state: Obsolete, cached: None
> ...
> Planned package: Product.msi, state: Obsolete, default requested: None,
> ba requested: None, execute: None, rollback: None, cache: No, uncache:
> No, dependency: None
> Planned related bundle: {BUNDLE_GUID}, type: Upgrade, default requested:
> Absent, ba requested: Absent, execute: Uninstall, rollback: Install,
> dependency: None
> ...
>
> It then proceeeds to uninstall the product but leave the new version in
> Add/Remove Programs.
>
> Any idea what I'm doing wrong?
>
> --
> Bruce Cran
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] New Bug and Feature Request location: http://wixtoolset.org/issues/

[Rob Mensching]

Neil and Phill,

I believe I've added enough to address both of these issues. Go to:
http://wixtoolset.org/issues/edit/me

There you should be able to update your username (and full name and email*)
as well as re-send the activation email. I've also fixed the DNS records.
The wixtoolset.org was missing it's SPF record and that likely contributed
to the email being treated as junk.

Note: updating your username, full name, and/or email will not
automatically update the information you see in existing bugs so do not be
alarmed if you see old data in bugs. The site caches data heavily and
you'll have to wait for the caches (on the server, not your client) to be
updated before your new username/full name/email shows up everywhere.



On Thu, Aug 22, 2013 at 12:59 PM, Bob Arnson  wrote:

> On 22-Aug-13 15:44, Phill Hogland wrote:
> > It prompted me for a login (or create an account) and I created a login
> and
> > logged in successfully.  I then tried to create a bug and it prompted
> for a
> > login and would not accept the credentials created a few seconds earlier.
> You have to activate your account first (by clicking the link in the
> mail the system should send).
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Custom element

[Rob Mensching]

It'd be great if you could contribute what you learned or maybe go in and
understand how the documentation is created for the WiX toolset to help
enhance it. The guys on wix-devs mailing list are very supportive of people
wanting to help improve.

Feature suggestions here are welcome but I always like to remind people
that to really make features a reality, we'll need contributors. 


On Tue, Aug 27, 2013 at 12:28 AM, Lars Lars  wrote:

> Hello,
>
> Reading the
> http://wixtoolset.org/documentation/manual/v3/xsd/wix/custom.html docs.
> Would it be possible to specify the legal values for attribute before and
> after, and inner value?
>
> Using google I found the state 'InstallInitialize' and 'InstallFinalize'
> which solved two issues. However it would be nice if the docs could have
> told me. I guess there might be other states aswell.
>
> For the inner text I used "NOT Installed" and "Installed", again based on
> google. In this case I am more confussed as to how it works. How does the
> installer know if something is installer or not? What other options do I
> have? What happens if I enter no inner text?
>
> Sorry for all the questions. Just thought I would give a feedback.
>
> Regards, Lars
>
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] 64 bit version of MS build cannot find the WIX toolset

[Rob Mensching]

There's an issue open requesting WiX to write the AssemblySearchPaths in
64-bit hive. That isn't done today.


On Tue, Aug 27, 2013 at 12:27 PM, Edwin Castro <0ptikgh...@gmx.us> wrote:

> MSBuild uses the AssemblySearchPaths property to determine the locations
> where it searches for assembly references. See
> http://msdn.microsoft.com/en-us/library/vstudio/bb629394.aspx
>
> You could either set the HintPath for the reference OR you could add the
> location of Microsoft.Deployment.WindowsInstaller.dll to
> AssemblySearchPaths with something like this:
>
> 
>   
> C:\Program Files (x86)\WiX Toolset v3.6\bin;
> $(AssemblySearchPaths)
>   
> 
>
> Note that you could possibly shadow other assemblies you depend on if
> they exist in WiX's bin directory (or whatever appropriate directory you
> use).
>
> My guess as to why 32-bit MSBuild (on the command line, not through
> Visual Studio) is that AssemblySearchPaths must be getting set with
> 32-bit only path. Perhaps something like C:\Program Files\WiX Toolset
> v3.6\bin which would only resolve for 32-bit processes... You can use
> the /verbose:diagnostic command line option to show you property values
> and a lot of other stuff you never cared about too!
>
>
> On 8/27/13 11:59 AM, John Cooper wrote:
> > That doesn't look right.  Bearing in mind that we're still using WiX 3.6
> RTM, my HintPath looks like:
> >
> > 
> >   ..\..\..\..\..\Program Files (x86)\WiX Toolset
> v3.6\bin\Microsoft.Deployment.WindowsInstaller.dll
> > 
> >
> > I don't think you're going to resolve an assembly without a hint path
> unless it's in the GAC.
> > --
> > John Merryweather Cooper
> > Build & Install Engineer -- ESA
> > Jack Henry & Associates, Inc.(r)
> > Shawnee Mission, KS  66227
> > Office:  913-341-3434 x791011
> > jocoo...@jackhenry.com
> > www.jackhenry.com
> >
> >
> >
> >
> > -Original Message-
> > From: Skildum, Mathew [mailto:mathew.skil...@aspect.com]
> > Sent: Tuesday, August 27, 2013 1:45 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] 64 bit version of MS build cannot find the WIX
> toolset
> >
> > The Microsoft.Deployment.WindowsInstaller assembly is located in the
> default installation location.  No customization has been done to the
> system or the projects.
> >
> > Here is the project file section that lists the above assembly
> refference:
> >   
> > 
> > 
> >   3.5
> > 
> > 
> >   False
> >
> ..\..\Assemblies\Powershell\System.Management.Automation.dll
> >   True
> > 
> > 
> > 
> >   
> >
> > Mat Skildum
> >
> >
> >
> >
> > -Original Message-
> > From: Edwin Castro [mailto:0ptikgh...@gmx.us]
> > Sent: Tuesday, August 27, 2013 1:13 PM
> > To: wix-users@lists.sourceforge.net
> > Subject: Re: [WiX-users] 64 bit version of MS build cannot find the WIX
> toolset
> >
> > On 8/27/13 11:03 AM, Skildum, Mathew wrote:
> >> All hint paths are correct as everything build correctly in Visual
> Studio (2010 and 2012).  The only time it fails is when I use the 64 bit
> version of MS Build.
> > Can you provide the reference XML from the project file? I assume you
> have not modified them manually, correct?
> >
> > --
> > Edwin G. Castro
> >
> >
> >
> --
> > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> > Discover the easy way to master current and previous Microsoft
> technologies and advance your career. Get an incredible 1,500+ hours of
> step-by-step tutorial videos with LearnDevNow. Subscribe today and save!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> --
> > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> > Discover the easy way to master current and previous Microsoft
> technologies and advance your career. Get an incredible 1,500+ hours of
> step-by-step tutorial videos with LearnDevNow. Subscribe today and save!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> > ___
> > 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, us

Re: [WiX-users] Burn, signature verification and failure on Vista

[Rob Mensching]

Often this on test VM machines but I suppose unmanaged machines not
connected to the internet would hit it.

Basically, you need to be connected to the internet occasionally to
participate in security since security changes over time (that which was
safe may become unsafe). Or so those that designed certificates say.

There isn't currently a way at runtime to ask Burn to skip verification. Of
course, you can do so at build time.

I'm quite torn over the value of signed packages. Honestly, just using
hashes is faster and less error prone.


On Tue, Aug 27, 2013 at 11:21 PM, Bruce Cran  wrote:

> I recently discovered the certificate auto-download feature in
> Vista/2008 when I found that our installer (which uses Burn) fails due
> to an authenticode verification error when the machine isn't connected
> to the Internet.  It seems that when Burn asks Windows to check the
> signature, if the root certificate is missing (which it will be if it's
> not been asked to check before) Windows downloads it from Microsoft. If
> it can't, verification fails and so does the installation.
>
> What I'm wondering is if this is only something likely to happen on test
> systems - in production is there some other way Windows is likely to
> have the updated certificates? Or, should I remove the signature on the
> installer and MSI file to avoid this problem?  Or is there a way to ask
> Burn to skip the verification step?
>
> --
> Bruce Cran
>
>
> --
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [SPAM] Re: FileSearch issues

[Rob Mensching]

I'm curious what happens when SourceDir is blank.


On Mon, Sep 2, 2013 at 10:25 AM, Phil Wilson  wrote:

> My dumb search works just fine - I can't see what the issue is. This works
> for me:
>
> Sample.msi and thing.txt in the same directory.
>
> 
>  Depth="0">
> 
> 
> 
>
> and a custom action in the execute sequence to display the value...
>
> msgbox
> session.property("FILEEXISTS")
>
> The custom action correctly shows the file path, and a log of the install
> shows:
>
> MSI (c) (28:38) [10:13:38:811]: PROPERTY CHANGE: Adding FILEEXISTS
> property. Its value is 'C:\Phil\MyDD\WiX  Samples\thing.txt'.
>
>
> So it does all work. I don't think an actual example with SourceDir was
> ever posted for a sanity check, but this is how to do it.
>
> Phil Wilson
>
>
> On Mon, Sep 2, 2013 at 9:19 AM, Edwin Castro <0ptikgh...@gmx.us> wrote:
>
> > I searched for WiX FileSearch in same directory as MSI on google. The
> > first hit [1] I received [2] includes a reply from Phil Wilson
> > suggesting the SourceDir [3] or OriginalDatabase [4] (with some
> > additional parsing) might work.
> >
> >
> >
> > [1]
> >
> >
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-get-the-current-directory-of-msi-is-running-from-td3058873.html
> > [2] I find it frustrating that different people can receive different
> > results. *sigh*
> > [3] http://msdn.microsoft.com/en-us/library/aa371857.aspx
> > [4] http://msdn.microsoft.com/en-us/library/aa370562.aspx
> >
> > --
> > Edwin G. Castro
> >
> > On 8/31/13 10:21 AM, Kai Peters wrote:
> > > Hi Edwin,
> > >
> > > no need to be suspicious of Depth and AssignToProperty (firstly,
> > omitting them didn't improve
> > > things, nor did I expect it to) as Depth can avoid unnecessary file
> > system traversal (don't know how
> > > deep the search would go if no Depth is specified but would assume that
> > default should be 0);
> > > AssignToProperty seems redundant to me as I would always expect the
> > innermost element of a nested
> > > search to be assigned - but I just put it in here to make things
> > absolutely clear.
> > >
> > > As I wrote (though not put in my example code) BOTH absolute and
> > variable path specifications fail -
> > > I would never use absolute paths in production.
> > >
> > > The idea behind this search is simply that our customers' IT people
> > could place a configuration file
> > > template beside our MSI and that during MSI execution this template
> > would be copied into its
> > > destination. Since I cannot know from where IT will deploy our MSIs, I
> > have to figure it out on the
> > > fly...
> > >
> > > And it's still failing - son if someone has an idea for me to look at,
> > I'd appreciate it
> > >
> > > Thanks,
> > > Kai
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thu, 29 Aug 2013 13:47:19 -0700, Edwin Castro wrote:
> > >> I'm highly suspect of the values for the Path, Depth and
> > >> AssignToProperty attributes in your DirectorySearch.
> > >>
> > >> The example sent by John Cooper, replicated below for convenience,
> > didn't set
> > >> AssignToProperty="no" nor Depth="0".
> > >>
> > >> 
> > >> 
> > >>
> > >> 
> > >> 
> >  > >> Id="WebFolderSearch" Path="Web">
> > >> 
> >  > >> Path="ProductName">  > Name="Web.config" /> 
> > >>
> > 
> > >>
> > >>
> > >> The Path value in your example is hard coded and that seems wrong to
> > me. Even if you can
> > >> guarantee that the MSI will ALWAYS reside at that location I believe
> > that caching by Windows
> > >> Installer will cause problems for you.
> > >>
> > >> My vague memory tells me that others have attempted this and couldn't
> > reliably determine where
> > >> the MSI was located in other to find a companion file located in the
> > same directory.
> > >>
> > >> An obvious workaround is to provide the path to the companion file via
> > a public property.
> > >>
> > >> --
> > >> Edwin G. Castro
> > >>
> > >> On 8/29/13 10:04 AM, K Peters wrote:
> > >>> Hi,
> > >>>
> > >>> I am still struggling with my FileSearch - no matter what I try, it
> > always pops up the "File
> > >>> does not exist next to MSI" message. I have tried using "SourceDir"
> as
> > well as the absolute
> > >>> path to where both the MSI & the inifile reside - same negative
> > results.
> > >>>
> > >>> Does anyone have an idea as to where I am screwing up...?
> > >>> Thanks, as always, for any pointers!
> > >>>
> > >>>
> > >>> 
> > >>>  > >>> Id="MI_DirSearch"
> > >>> Path="C:\Wix_Installscripts\Release_3.1.3\Regular_Install\" Depth="0"
> > AssignToProperty="no">
> > >>> 
> 
> > 
> > >>>
> > >>> 
> > >>> 
> > >>> 
> > >>>
> > >>> 
> > >>> 
> > >>> 
> > >>>
> >
> --
> > Learn the latest-
> > >>> -Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the
> > easy way to master current
> > >>> and previous Microsoft technologies and advance your career. Get an
> > incredible 

Re: [WiX-users] Launching Bootstrapper executable should only show the internal MSI interface.

[Rob Mensching]

Yes. You need a custom BA.


On Wed, Sep 4, 2013 at 3:49 AM, ak m  wrote:

> Dear All,
>
> Launching Bootstrapper executable should only show the internal MSI
> interface.
>
> Not to show any of the Bootstrapper UI.
>
> Is this Possible?
>
> Any one please help me on this?
>
>
> Thanks in Advance.
>
> Anil
>
> --
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ARPSYSTEMCOMPONENT and patches

[Rob Mensching]

Ship the patch in a Bundle.


On Wed, Sep 4, 2013 at 10:04 AM, George Fleming wrote:

> I have two applications, a MSI and a bootstrapper/UI that invokes the MSI.
>  To prevent double ARP entries, we set the ARPSYSTEMCOMPONENT property in
> the bootstrapper .
>
> This works fine, except when we apply a patch.  Because the MSI is
> blocked, so is its patch.  We cannot see it, and therefore cannot uninstall
> the patch.
>
> If I force it to show up in ARP by adding registry entries, a patch that
> is applied to a MSI install (not through bootstrapper) now shows double
> patch entries in the ARP.
>
> What is correct way to handle this problem?  I'm using Wix 3.6.
>
> Thanks,
>
> George
>
>
> --
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [SPAM] Re: Updated login to: http://wixtoolset.org/issues/

[Rob Mensching]

Manual is expected to be working now so if you find dead links, please do
file bugs about them.


On Wed, Sep 4, 2013 at 11:08 AM, Phill Hogland  wrote:

> Sorry for the delay in responding to the last post.  I updated my user info
> using the link provided in the email, however it always failed until I used
> exactly the same optional 'user name' provided originally.  Then it liked
> the new password, and I can now log into the new bug tracker.  Thanks for
> all of this work! Impressive. The new manual has a few broken links, which
> I
> can point out if that would be helpful, but I don't want to be a pest about
> something that is in transition.  Thanks.  Phill
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/New-Bug-and-Feature-Request-location-http-wixtoolset-org-issues-tp7588281p7588759.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] VS2013?

[Rob Mensching]

There are bugs open that track progress of 2013 support.


On Wed, Sep 4, 2013 at 11:16 AM, John H Bergman (XPedient) <
john.berg...@xpdnt.com> wrote:

> I noticed while looking through the history that there were checkins
> related to VS2013 Preview, including a branch merge.  Does this mean that
> 2013 is supported now (at least the preview version)?
>
> Thanks,
> John
>
>
> --
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [SPAM] Re: FileSearch issues

[Rob Mensching]

My memory says SourceDir is blank until Source Resolution is executed.


On Wed, Sep 4, 2013 at 10:13 AM, Phil Wilson  wrote:

> It will work only during first install, as Rob most likely knows. During
> repair, feature change, and uninstall the SourceDir location is (IIRC) the
> installer directory of the cached MSI file.
>
> It's not good design to rely on external files in the same location as the
> MSI. There are too many failure points, as just mentioned. Also, Group
> Policy and web installs don't work, and a simple mistake in staging the MSI
> file and the external file to the install source changes the install logic,
> and that probably can't be corrected later. If there is really a need for
> an optional external file it would be better to have it in the binary table
> or have the data as properties, and give customers a tool to add the file
> (or the data) if necessary. Or change the design.
>
> Phil Wilson
>
>
> On Wed, Sep 4, 2013 at 7:15 AM, Kai Peters  wrote:
>
> > Phil,
> >
> > your sample code works for me as well. Off to see where mine is
> > different...
> >
> >
> > On Mon, 2 Sep 2013 10:25:03 -0700, Phil Wilson wrote:
> > > My dumb search works just fine - I can't see what the issue is. This
> > works for me:
> > >
> > > Sample.msi and thing.txt in the same directory.
> > >
> > > 
> > > 
> >  > > Name="thing.txt" />  
> > >
> > > and a custom action in the execute sequence to display the value...
> > >
> > > msgbox
> > > session.property("FILEEXISTS")
> > >
> > > The custom action correctly shows the file path, and a log of the
> > install shows:
> > >
> > > MSI (c) (28:38) [10:13:38:811]: PROPERTY CHANGE: Adding FILEEXISTS
> > property. Its value is
> > > 'C:\Phil\MyDD\WiX  Samples\thing.txt'.
> > >
> > >
> > > So it does all work. I don't think an actual example with SourceDir was
> > ever posted for a sanity
> > > check, but this is how to do it.
> > >
> > > Phil Wilson
> > >
> > >
> > > On Mon, Sep 2, 2013 at 9:19 AM, Edwin Castro <0ptikgh...@gmx.us>
> wrote:
> > >
> > >> I searched for WiX FileSearch in same directory as MSI on google. The
> > first hit [1] I received
> > >> [2] includes a reply from Phil Wilson suggesting the SourceDir [3] or
> > OriginalDatabase [4]
> > >> (with some additional parsing) might work.
> > >>
> > >>
> > >> [1]
> > >>
> > >>
> >
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-get-the-current-directory-
> > >> of-msi-is-running-from-td3058873.html
> > >> [2] I find it frustrating that different people can receive different
> > results. *sigh*
> > >> [3] http://msdn.microsoft.com/en-us/library/aa371857.aspx [4]
> > http://msdn.microsoft.com/en-
> > >> us/library/aa370562.aspx
> > >>
> > >> --
> > >> Edwin G. Castro
> > >>
> > >> On 8/31/13 10:21 AM, Kai Peters wrote:
> > >>> Hi Edwin,
> > >>>
> > >>> no need to be suspicious of Depth and AssignToProperty (firstly,
> > >>>
> > >> omitting them didn't improve
> > >>> things, nor did I expect it to) as Depth can avoid unnecessary file
> > >>>
> > >> system traversal (don't know how
> > >>> deep the search would go if no Depth is specified but would assume
> that
> > >>>
> > >> default should be 0);
> > >>> AssignToProperty seems redundant to me as I would always expect the
> > >>>
> > >> innermost element of a nested
> > >>> search to be assigned - but I just put it in here to make things
> > >>>
> > >> absolutely clear.
> > >>
> > >>> As I wrote (though not put in my example code) BOTH absolute and
> > >>>
> > >> variable path specifications fail -
> > >>> I would never use absolute paths in production.
> > >>>
> > >>> The idea behind this search is simply that our customers' IT people
> > >>>
> > >> could place a configuration file
> > >>> template beside our MSI and that during MSI execution this template
> > >>>
> > >> would be copied into its
> > >>> destination. Since I cannot k

Re: [WiX-users] Uninstall bundle by name ?

[Rob Mensching]

Nothing that is documented today.


On Wed, Sep 4, 2013 at 3:57 PM,  wrote:

> Hi all - I've managed to upgrade some of our installs to Wix 3.7 with the
> burn bootstrapper, hooray !
>
> One thing I haven't quite anticipated is this: after our automated build
> we need to push a newly-built installer to a test machine for an automated
> smoke/sanity test.  First we need to uninstall the old build and install
> the new one (silently, can't just use control panel).  I know it's possible
> to run the old Setup.exe with the "/quiet /uninstall" command-line params,
> but is that the only way ?
>
> With MSI's we could run "msiexec /x {product ID}" to do the uninstall.  Is
> there some way to silently run the uninstall by product name or some other
> ID which doesn't change from build to build ?  It would be nice not to have
> to keep the old bundle around for the uninstall.
>
> Thanks for any info !
> -Rob
>
>
> --
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users