date:20121218

Re: [WiX-users] Condition a Merge module to be installed or skipped

2012-12-18 Thread Rob Mensching

You could Condition the Feature the Merge Module is merged into.


On Tue, Dec 18, 2012 at 5:48 PM, vlicaros  wrote:

> I have a 3rd party merge module (MSM) which consists of an SDK.  I want to
> be
> able to detect that the SDK is already installed (which i've done with
> RegistrySearch).
> Is it possible for WIX to decide either to install the MSM if the
> RegistrySeach returns false and to not to install if the RegistrySearch
> returns true.
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Condition-a-Merge-module-to-be-installed-or-skipped-tp7582454.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
virtually,

   Rob Mensching
   http://RobMensching.com LLC
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Registry search and condition message in installer

2012-12-18 Thread Steven Ogilvie

Oops I should have said as well...

The 32 bit version is checked and correct since it is installed so the logic is 
correct for the 32 bit check of  it's 
the 64bit check that is failing on the 32 bit OS

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: December-18-12 7:19 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Registry search and condition message in installer

I always use a verbose log file to check the values of Properties since that 
where I usually make my mistakes.


On Tue, Dec 18, 2012 at 3:14 PM, StevenOgilvie  wrote:

> I have a 32 bit installer, it can run on a 32 bit or a 64 bit OS...
> On the 32 bit OS only the 32 bit pre requisites are run, but on the 64 
> bit OS both 32/64 bit pre requisites are run.
>
> The installer verifies that the pre requisites are installed (ya its 
> overkill but that is another story)...
>
> On a 64 bit machine all works fine, on a 32 bit OS I am running into 
> errors where the condition message displays even though it shouldn't, 
> I have been playing around with this for too long, what am I doing 
> wrong? thanks in advance...
>
> Registry check:
>
> 
>   
>
> Key="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{7AC8EF88-D996-4D47-B40C-4DD93E307481}"
>   Name="DisplayVersion"
>   Root="HKLM"
>   Type="raw"
>   Win64="no"/>
>   
>
> 
>   
>
> Key="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{A4E269C1-168D-40D3-9ABD-57FE4D4DB537}"
>   Name="DisplayVersion"
>   Root="HKLM"
>   Type="raw"
>   Win64="yes"/>
>   
>
> Condition Message:
> http://www.microsoft.com/en-us/download/default.aspx  
> then restart the $(var.ProductName) setup.">
>   < ! [ CDATA [Installed OR (SQLSYNCX86SEARCH > "0")]]>
> 
> http://www.microsoft.com/en-us/download/default.aspx  
> then restart the $(var.ProductName) setup.">
>   < ! [CDATA [(Installed OR (SQLSYNCX64SEARCH > "0" AND VersionNT64)]]>
> 
>
> BTW I have added spaces < ! [ CDATA because nabble doesn't like this 
> :) Steve
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Registry
> -search-and-condition-message-in-installer-tp7582450.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
>  LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free 
> Trial Remotely access PCs and mobile devices and provide instant 
> support Improve your efficiency, and focus on delivering more 
> value-add services Discover what IT Professionals Know. Rescue 
> delivers http://p.sf.net/sfu/logmein_12329d2d
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



--
virtually,

   Rob Mensching
   http://RobMensching.com LLC
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely 
access PCs and mobile devices and provide instant support Improve your 
efficiency, and focus on delivering more value-add services Discover what IT 
Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Registry search and condition message in installer

2012-12-18 Thread Steven Ogilvie

The thing is... its windows7 32 bit, so that registry key won't be there which 
means the value should be 0 and that VersionNT64 is false so my logic is 
incorrect but I have tried multiple things :(

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: December-18-12 7:19 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Registry search and condition message in installer

I always use a verbose log file to check the values of Properties since that 
where I usually make my mistakes.


On Tue, Dec 18, 2012 at 3:14 PM, StevenOgilvie  wrote:

> I have a 32 bit installer, it can run on a 32 bit or a 64 bit OS...
> On the 32 bit OS only the 32 bit pre requisites are run, but on the 64 
> bit OS both 32/64 bit pre requisites are run.
>
> The installer verifies that the pre requisites are installed (ya its 
> overkill but that is another story)...
>
> On a 64 bit machine all works fine, on a 32 bit OS I am running into 
> errors where the condition message displays even though it shouldn't, 
> I have been playing around with this for too long, what am I doing 
> wrong? thanks in advance...
>
> Registry check:
>
> 
>   
>
> Key="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{7AC8EF88-D996-4D47-B40C-4DD93E307481}"
>   Name="DisplayVersion"
>   Root="HKLM"
>   Type="raw"
>   Win64="no"/>
>   
>
> 
>   
>
> Key="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{A4E269C1-168D-40D3-9ABD-57FE4D4DB537}"
>   Name="DisplayVersion"
>   Root="HKLM"
>   Type="raw"
>   Win64="yes"/>
>   
>
> Condition Message:
> http://www.microsoft.com/en-us/download/default.aspx  
> then restart the $(var.ProductName) setup.">
>   < ! [ CDATA [Installed OR (SQLSYNCX86SEARCH > "0")]]>
> 
> http://www.microsoft.com/en-us/download/default.aspx  
> then restart the $(var.ProductName) setup.">
>   < ! [CDATA [(Installed OR (SQLSYNCX64SEARCH > "0" AND VersionNT64)]]>
> 
>
> BTW I have added spaces < ! [ CDATA because nabble doesn't like this 
> :) Steve
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Registry
> -search-and-condition-message-in-installer-tp7582450.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
>  LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free 
> Trial Remotely access PCs and mobile devices and provide instant 
> support Improve your efficiency, and focus on delivering more 
> value-add services Discover what IT Professionals Know. Rescue 
> delivers http://p.sf.net/sfu/logmein_12329d2d
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



--
virtually,

   Rob Mensching
   http://RobMensching.com LLC
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely 
access PCs and mobile devices and provide instant support Improve your 
efficiency, and focus on delivering more value-add services Discover what IT 
Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Condition a Merge module to be installed or skipped

2012-12-18 Thread vlicaros

I have a 3rd party merge module (MSM) which consists of an SDK.  I want to be
able to detect that the SDK is already installed (which i've done with
RegistrySearch).
Is it possible for WIX to decide either to install the MSM if the
RegistrySeach returns false and to not to install if the RegistrySearch
returns true.



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Condition-a-Merge-module-to-be-installed-or-skipped-tp7582454.html
Sent from the wix-users mailing list archive at Nabble.com.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Registry search and condition message in installer

2012-12-18 Thread Rob Mensching

I always use a verbose log file to check the values of Properties since
that where I usually make my mistakes.


On Tue, Dec 18, 2012 at 3:14 PM, StevenOgilvie  wrote:

> I have a 32 bit installer, it can run on a 32 bit or a 64 bit OS...
> On the 32 bit OS only the 32 bit pre requisites are run, but on the 64 bit
> OS both 32/64 bit pre requisites are run.
>
> The installer verifies that the pre requisites are installed (ya its
> overkill but that is another story)...
>
> On a 64 bit machine all works fine, on a 32 bit OS I am running into errors
> where the condition message displays even though it shouldn't, I have been
> playing around with this for too long, what am I doing wrong? thanks in
> advance...
>
> Registry check:
>
> 
>   
>
> Key="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{7AC8EF88-D996-4D47-B40C-4DD93E307481}"
>   Name="DisplayVersion"
>   Root="HKLM"
>   Type="raw"
>   Win64="no"/>
>   
>
> 
>   
>
> Key="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{A4E269C1-168D-40D3-9ABD-57FE4D4DB537}"
>   Name="DisplayVersion"
>   Root="HKLM"
>   Type="raw"
>   Win64="yes"/>
>   
>
> Condition Message:
> http://www.microsoft.com/en-us/download/default.aspx  then
> restart the $(var.ProductName) setup.">
>   < ! [ CDATA [Installed OR (SQLSYNCX86SEARCH > "0")]]>
> 
> http://www.microsoft.com/en-us/download/default.aspx  then
> restart the $(var.ProductName) setup.">
>   < ! [CDATA [(Installed OR (SQLSYNCX64SEARCH > "0" AND VersionNT64)]]>
> 
>
> BTW I have added spaces < ! [ CDATA because nabble doesn't like this :)
> Steve
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Registry-search-and-condition-message-in-installer-tp7582450.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
virtually,

   Rob Mensching
   http://RobMensching.com LLC
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Are "*" Component Guids trustworthy (for IIS subdirectory)?

2012-12-18 Thread Rob Mensching

Yes, feature is good to go now.


On Tue, Dec 18, 2012 at 2:14 PM, john.burak  wrote:

> I'm converting some InstallShield installers to Wix.  I was planning to use
> Heat to harvest the "dynamic directories" so our process can remain the
> same.  I wanted to use the -ag flag to generate component guids at compile
> time.
>
> The directory is to be installed under the IIS wwwroot folder.  Because
> that's a non-well-known directory, I had to use a
> ComponentGuidGenerationSeed.  Do I need to force the wwwroot directory to a
> certain drive for this to work safely (especially if
> patching/updating/upgrading)?
>
> I came across an  old (2008) email
> <
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Autogen-GUIDs-for-components-tp1457185p1459008.html
> >
> from Rob, saying auto-generated component guids were experimental.  Is this
> feature ready for production?
>
> Thanks!
>
> - John
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Are-Component-Guids-trustworthy-for-IIS-subdirectory-tp7582449.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
virtually,

   Rob Mensching
   http://RobMensching.com LLC
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Registry search and condition message in installer

2012-12-18 Thread StevenOgilvie

I have a 32 bit installer, it can run on a 32 bit or a 64 bit OS...
On the 32 bit OS only the 32 bit pre requisites are run, but on the 64 bit
OS both 32/64 bit pre requisites are run.

The installer verifies that the pre requisites are installed (ya its
overkill but that is another story)...

On a 64 bit machine all works fine, on a 32 bit OS I am running into errors
where the condition message displays even though it shouldn't, I have been
playing around with this for too long, what am I doing wrong? thanks in
advance...

Registry check:


  
  


  
  

Condition Message:
http://www.microsoft.com/en-us/download/default.aspx  then
restart the $(var.ProductName) setup.">
  < ! [ CDATA [Installed OR (SQLSYNCX86SEARCH > "0")]]>

http://www.microsoft.com/en-us/download/default.aspx  then
restart the $(var.ProductName) setup.">
  < ! [CDATA [(Installed OR (SQLSYNCX64SEARCH > "0" AND VersionNT64)]]>


BTW I have added spaces < ! [ CDATA because nabble doesn't like this :)
Steve



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Registry-search-and-condition-message-in-installer-tp7582450.html
Sent from the wix-users mailing list archive at Nabble.com.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Are "*" Component Guids trustworthy (for IIS subdirectory)?

2012-12-18 Thread john.burak

I'm converting some InstallShield installers to Wix.  I was planning to use
Heat to harvest the "dynamic directories" so our process can remain the
same.  I wanted to use the -ag flag to generate component guids at compile
time.

The directory is to be installed under the IIS wwwroot folder.  Because
that's a non-well-known directory, I had to use a
ComponentGuidGenerationSeed.  Do I need to force the wwwroot directory to a
certain drive for this to work safely (especially if
patching/updating/upgrading)?

I came across an  old (2008) email

  
from Rob, saying auto-generated component guids were experimental.  Is this
feature ready for production?

Thanks!

- John



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Are-Component-Guids-trustworthy-for-IIS-subdirectory-tp7582449.html
Sent from the wix-users mailing list archive at Nabble.com.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Error 0x80070643: Failed to install MSI package.

2012-12-18 Thread Rob Mensching

That's the generic ERROR_INSTALL_FAILURE - "Fatal error during
installation." error code. Take a look at the appropriate MSI log file to
see why the MSI is failing.


On Tue, Dec 18, 2012 at 1:14 PM, Dave Gilmour (FET) wrote:

> I have an installation package that seems to be working on all of the
> machines we've tested on so far except one.
>
> The errors indicated in the log are:
>
> 06F4:1D44][2012-12-18T14:05:28]e000: Error 0x80070643: Failed to install
> MSI package.
> [06F4:1D44][2012-12-18T14:05:28]e000: Error 0x80070643: Failed to
> execute MSI package.
> [0D7C:17D4][2012-12-18T14:05:28]e000: Error 0x80070643: Failed to
> configure per-machine MSI package.
>
> Doing a search for these errors, I found the closed bug report #2677
> which seems to be similar, but apparently was specific to v3.6 and has
> since been resolved.  I'm using v3.7 so I'm presuming the issues
> indicated in that bug report are not applicable to my situation.
>
> The complete log is attached below.  I'd appreciate any hints as to what
> might be causing this issue.
>
> Thanks.
>
> Dave
>
> [0D7C:17D4][2012-12-18T14:04:17]i001: Burn v3.7.1126.0, Windows v6.1
> (Build 7601: Service Pack 1), path:
> C:\wipezone\wipezone\RapidFET3Setup_3_2_003.exe, cmdline: ''
> [0D7C:17D4][2012-12-18T14:04:17]i000: Initializing string variable
> 'InstallFolder' to value '[ProgramFilesFolder]FETCorp\RapidFET3'
> [0D7C:17D4][2012-12-18T14:04:17]i000: Setting string variable
> 'WixBundleLog' to value
> 'C:\Users\FET\AppData\Local\Temp\RapidFET3_20121218140417.log'
> [0D7C:17D4][2012-12-18T14:04:17]i000: Setting string variable
> 'WixBundleOriginalSource' to value
> 'C:\wipezone\wipezone\RapidFET3Setup_3_2_003.exe'
> [0D7C:17D4][2012-12-18T14:04:17]i052: Condition '((VersionNT >= v5.1)
> AND (ServicePackLevel >= 3)) OR (VersionNT >= v6.0)' evaluates to true.
> [0D7C:17D4][2012-12-18T14:04:17]i000: Setting string variable
> 'WixBundleName' to value 'RapidFET3'
> [0D7C:17D4][2012-12-18T14:04:17]i100: Detect begin, 17 packages
> [0D7C:17D4][2012-12-18T14:04:17]i103: Detected related package:
> {0D8E57FA-1914-4A6A-BAC3-C13E6AD3B614}, scope: PerMachine, version:
> 3.2.1.0, language: 0 operation: MajorUpgrade
> [0D7C:17D4][2012-12-18T14:04:17]i103: Detected related package:
> {C74C2E29-CE2B-4640-B118-152E71B51136}, scope: PerMachine, version:
> 3.0.2.0, language: 0 operation: MajorUpgrade
> [0D7C:17D4][2012-12-18T14:04:17]i103: Detected related package:
> {997E36F2-0F28-424C-B3A8-B31FC312259B}, scope: PerMachine, version:
> 3.0.2.0, language: 0 operation: MajorUpgrade
> [0D7C:17D4][2012-12-18T14:04:17]i103: Detected related package:
> {478C5C07-109F-452B-AC42-45055E224641}, scope: PerMachine, version:
> 3.0.2.0, language: 0 operation: MajorUpgrade
> [0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: hasp, state:
> Absent, cached: None
> [0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: RapidFET, state:
> Absent, cached: None
> [0D7C:17D4][2012-12-18T14:04:17]i101: Detected package:
> RapidFET3_IDT80KSW0002_Setup.msi, state: Absent, cached: Complete
> [0D7C:17D4][2012-12-18T14:04:17]i101: Detected package:
> RapidFET3_IDT80KSW0003_Setup.msi, state: Absent, cached: Complete
> [0D7C:17D4][2012-12-18T14:04:17]i101: Detected package:
> RapidFET3_IDT80KSW0004_Setup.msi, state: Absent, cached: Complete
> [0D7C:17D4][2012-12-18T14:04:17]i101: Detected package:
> RapidFET3_IDT80KSW0005_Setup.msi, state: Absent, cached: Complete
> [0D7C:17D4][2012-12-18T14:04:17]i101: Detected package:
> RapidFET3_IDT_CPS1432_Setup.msi, state: Absent, cached: Complete
> [0D7C:17D4][2012-12-18T14:04:17]i101: Detected package:
> RapidFET3_IDT_CPS1616_Setup.msi, state: Absent, cached: Complete
> [0D7C:17D4][2012-12-18T14:04:17]i101: Detected package:
> RapidFET3_IDT_CPS1848_Setup.msi, state: Absent, cached: Complete
> [0D7C:17D4][2012-12-18T14:04:17]i101: Detected package:
> RapidFET3_Tsi564_Setup.msi, state: Absent, cached: Complete
> [0D7C:17D4][2012-12-18T14:04:17]i101: Detected package:
> RapidFET3_Tsi568_Setup.msi, state: Absent, cached: Complete
> [0D7C:17D4][2012-12-18T14:04:17]i101: Detected package:
> RapidFET3_Tsi572_Setup.msi, state: Absent, cached: Complete
> [0D7C:17D4][2012-12-18T14:04:17]i101: Detected package:
> RapidFET3_Tsi574_Setup.msi, state: Absent, cached: Complete
> [0D7C:17D4][2012-12-18T14:04:17]i101: Detected package:
> RapidFET3_Tsi576_Setup.msi, state: Absent, cached: Complete
> [0D7C:17D4][2012-12-18T14:04:17]i101: Detected package:
> RapidFET3_Tsi577_Setup.msi, state: Absent, cached: Complete
> [0D7C:17D4][2012-12-18T14:04:17]i101: Detected package:
> RapidFET3_Tsi578_Setup.msi, state: Absent, cached: Complete
> [0D7C:17D4][2012-12-18T14:04:17]i101: Detected package:
> RapidFET3_Tsi721_Setup.msi, state: Absent, cached: Complete
> [0D7C:17D4][2012-12-18T14:04:17]i199: Detect complete, result: 0x0
> [0D7C:17D4][2012-12-18T14:04:34]i200: Plan begin, 17 packages, action:
> Install
> [0D7C:17D4][2012-12-18T14:04:34]w321: Skipping dependency registra

Re: [WiX-users] Error 0x80070643: Failed to install MSI package.

2012-12-18 Thread Neil Sleightholm

You need to look in the log file for RapidFETAppSetup.msi that should show the 
actual error (search for "value 3" and look near there).

Neil

-Original Message-
From: Dave Gilmour (FET) [mailto:d...@fetcorp.com] 
Sent: 18 December 2012 21:15
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Error 0x80070643: Failed to install MSI package.

I have an installation package that seems to be working on all of the machines 
we've tested on so far except one.

The errors indicated in the log are:

06F4:1D44][2012-12-18T14:05:28]e000: Error 0x80070643: Failed to install MSI 
package.
[06F4:1D44][2012-12-18T14:05:28]e000: Error 0x80070643: Failed to execute MSI 
package.
[0D7C:17D4][2012-12-18T14:05:28]e000: Error 0x80070643: Failed to configure 
per-machine MSI package.

Doing a search for these errors, I found the closed bug report #2677 which 
seems to be similar, but apparently was specific to v3.6 and has since been 
resolved.  I'm using v3.7 so I'm presuming the issues indicated in that bug 
report are not applicable to my situation.

The complete log is attached below.  I'd appreciate any hints as to what might 
be causing this issue.

Thanks.

Dave

[0D7C:17D4][2012-12-18T14:04:17]i001: Burn v3.7.1126.0, Windows v6.1 (Build 
7601: Service Pack 1), path: 
C:\wipezone\wipezone\RapidFET3Setup_3_2_003.exe, cmdline: ''
[0D7C:17D4][2012-12-18T14:04:17]i000: Initializing string variable 
'InstallFolder' to value '[ProgramFilesFolder]FETCorp\RapidFET3'
[0D7C:17D4][2012-12-18T14:04:17]i000: Setting string variable 'WixBundleLog' to 
value 'C:\Users\FET\AppData\Local\Temp\RapidFET3_20121218140417.log'
[0D7C:17D4][2012-12-18T14:04:17]i000: Setting string variable 
'WixBundleOriginalSource' to value 
'C:\wipezone\wipezone\RapidFET3Setup_3_2_003.exe'
[0D7C:17D4][2012-12-18T14:04:17]i052: Condition '((VersionNT >= v5.1) AND 
(ServicePackLevel >= 3)) OR (VersionNT >= v6.0)' evaluates to true.
[0D7C:17D4][2012-12-18T14:04:17]i000: Setting string variable 'WixBundleName' 
to value 'RapidFET3'
[0D7C:17D4][2012-12-18T14:04:17]i100: Detect begin, 17 packages
[0D7C:17D4][2012-12-18T14:04:17]i103: Detected related package: 
{0D8E57FA-1914-4A6A-BAC3-C13E6AD3B614}, scope: PerMachine, version: 
3.2.1.0, language: 0 operation: MajorUpgrade
[0D7C:17D4][2012-12-18T14:04:17]i103: Detected related package: 
{C74C2E29-CE2B-4640-B118-152E71B51136}, scope: PerMachine, version: 
3.0.2.0, language: 0 operation: MajorUpgrade
[0D7C:17D4][2012-12-18T14:04:17]i103: Detected related package: 
{997E36F2-0F28-424C-B3A8-B31FC312259B}, scope: PerMachine, version: 
3.0.2.0, language: 0 operation: MajorUpgrade
[0D7C:17D4][2012-12-18T14:04:17]i103: Detected related package: 
{478C5C07-109F-452B-AC42-45055E224641}, scope: PerMachine, version: 
3.0.2.0, language: 0 operation: MajorUpgrade
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: hasp, state: 
Absent, cached: None
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: RapidFET, state: 
Absent, cached: None
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_IDT80KSW0002_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_IDT80KSW0003_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_IDT80KSW0004_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_IDT80KSW0005_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_IDT_CPS1432_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_IDT_CPS1616_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_IDT_CPS1848_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_Tsi564_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_Tsi568_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_Tsi572_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_Tsi574_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_Tsi576_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_Tsi577_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_Tsi578_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_Tsi721_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i199: Detect complete, result: 0x0
[0D7C:17D4][2012-12-18T14:04:34]i200: Plan begin, 17 packages, action: 
Install
[0D7C:17D4][2012-12-18T14:04:34]w321: Skipp

[WiX-users] Error 0x80070643: Failed to install MSI package.

2012-12-18 Thread Dave Gilmour (FET)

I have an installation package that seems to be working on all of the 
machines we've tested on so far except one.

The errors indicated in the log are:

06F4:1D44][2012-12-18T14:05:28]e000: Error 0x80070643: Failed to install 
MSI package.
[06F4:1D44][2012-12-18T14:05:28]e000: Error 0x80070643: Failed to 
execute MSI package.
[0D7C:17D4][2012-12-18T14:05:28]e000: Error 0x80070643: Failed to 
configure per-machine MSI package.

Doing a search for these errors, I found the closed bug report #2677 
which seems to be similar, but apparently was specific to v3.6 and has 
since been resolved.  I'm using v3.7 so I'm presuming the issues 
indicated in that bug report are not applicable to my situation.

The complete log is attached below.  I'd appreciate any hints as to what 
might be causing this issue.

Thanks.

Dave

[0D7C:17D4][2012-12-18T14:04:17]i001: Burn v3.7.1126.0, Windows v6.1 
(Build 7601: Service Pack 1), path: 
C:\wipezone\wipezone\RapidFET3Setup_3_2_003.exe, cmdline: ''
[0D7C:17D4][2012-12-18T14:04:17]i000: Initializing string variable 
'InstallFolder' to value '[ProgramFilesFolder]FETCorp\RapidFET3'
[0D7C:17D4][2012-12-18T14:04:17]i000: Setting string variable 
'WixBundleLog' to value 
'C:\Users\FET\AppData\Local\Temp\RapidFET3_20121218140417.log'
[0D7C:17D4][2012-12-18T14:04:17]i000: Setting string variable 
'WixBundleOriginalSource' to value 
'C:\wipezone\wipezone\RapidFET3Setup_3_2_003.exe'
[0D7C:17D4][2012-12-18T14:04:17]i052: Condition '((VersionNT >= v5.1) 
AND (ServicePackLevel >= 3)) OR (VersionNT >= v6.0)' evaluates to true.
[0D7C:17D4][2012-12-18T14:04:17]i000: Setting string variable 
'WixBundleName' to value 'RapidFET3'
[0D7C:17D4][2012-12-18T14:04:17]i100: Detect begin, 17 packages
[0D7C:17D4][2012-12-18T14:04:17]i103: Detected related package: 
{0D8E57FA-1914-4A6A-BAC3-C13E6AD3B614}, scope: PerMachine, version: 
3.2.1.0, language: 0 operation: MajorUpgrade
[0D7C:17D4][2012-12-18T14:04:17]i103: Detected related package: 
{C74C2E29-CE2B-4640-B118-152E71B51136}, scope: PerMachine, version: 
3.0.2.0, language: 0 operation: MajorUpgrade
[0D7C:17D4][2012-12-18T14:04:17]i103: Detected related package: 
{997E36F2-0F28-424C-B3A8-B31FC312259B}, scope: PerMachine, version: 
3.0.2.0, language: 0 operation: MajorUpgrade
[0D7C:17D4][2012-12-18T14:04:17]i103: Detected related package: 
{478C5C07-109F-452B-AC42-45055E224641}, scope: PerMachine, version: 
3.0.2.0, language: 0 operation: MajorUpgrade
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: hasp, state: 
Absent, cached: None
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: RapidFET, state: 
Absent, cached: None
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_IDT80KSW0002_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_IDT80KSW0003_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_IDT80KSW0004_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_IDT80KSW0005_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_IDT_CPS1432_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_IDT_CPS1616_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_IDT_CPS1848_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_Tsi564_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_Tsi568_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_Tsi572_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_Tsi574_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_Tsi576_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_Tsi577_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_Tsi578_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i101: Detected package: 
RapidFET3_Tsi721_Setup.msi, state: Absent, cached: Complete
[0D7C:17D4][2012-12-18T14:04:17]i199: Detect complete, result: 0x0
[0D7C:17D4][2012-12-18T14:04:34]i200: Plan begin, 17 packages, action: 
Install
[0D7C:17D4][2012-12-18T14:04:34]w321: Skipping dependency registration 
on package with no dependency providers: hasp
[0D7C:17D4][2012-12-18T14:04:34]i000: Setting string variable 
'WixBundleLog_hasp' to value 
'C:\Users\FET\AppData\Local\Temp\RapidFET3_20121218140417_0_hasp.log'
[0D7C:17D4][2012-12-18T14:04:34]i000: Setting string variable 
'WixBundleRollbackLog_RapidFET' to value 
'C:\Users\FET\AppData\Local\Temp\Rapi

Re: [WiX-users] WiX 3.6 upgrading perUser to perMachine

2012-12-18 Thread Hoover, Jacob

Could you not change your product code of your MSI, and enforce this new one is 
per machine only? Then with burn, you could detect the previous product code 
and uninstall it if found (this would only work if the same user was installing 
the per machine as the one who installed it per user).  Or is the problem that 
burn detects it but isn't able to remove it because it was per user but 
required elevation? 

I still find it strange you had a per user MSI capable of installing to the 
program files folder.

-Original Message-
From: Derek Wickern [mailto:dwick...@gmail.com] 
Sent: Tuesday, December 18, 2012 1:09 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WiX 3.6 upgrading perUser to perMachine

I would really appreciate some help with this. As it is, I can't upgrade to 
Burn because the installer no longer has privileges to write to ProgramFiles in 
per-user mode.

I found this post from 2009:

http://stackoverflow.com/a/678190
>Sadly, the Windows Installer doesn't support that. Some process outside your 
>package (a bootstrapper/chainer?) will have to manage the upgrade from 
>per-user to per-machine.

Now there is an official bootstrapper. How can I best use it to upgrade 
per-user to per-machine?

On 11/28/12, Derek Wickern  wrote:
> It looks like I can use MsiEnumRelatedProducts to find the existing 
> products by upgrade code. I can't uninstall the old products from a 
> custom action, but I should be able to use the bootstrapper for that.
> I know there will be difficulty uninstalling a product which was 
> installed by another user, but I don't think I can solve that. I'm 
> just hoping to achieve a smooth upgrade path for most users.
>
> What's the best way to run my custom code from burn? Should I write a 
> managed bootstrapper application?
>
> On 11/27/12, Philip Patrick  wrote:
>> Well, not sure ours was the best solution, but what we did is a 
>> custom action that literally moves all registry entries related to 
>> per-user package to per-machine. That means from 
>> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\SID
>> -OF-USER to UserData\S-1-5-18 (latter stores per-machine 
>> installations).
>>
>> We decided to go this way because:
>> 1. It is not possible to uninstall another MSI from custom action 
>> since Windows Installer doesn't allow concurrent installations 2. 
>> Per-user installation could have been installed with different user 
>> than the one performing upgrade - this way MSI  will not "see" that 
>> there is something installed. At least we saw this behavior from our 
>> investigations.
>>
>> Today, I wouldn't recommend going this way - it is too buggy. Instead 
>> I would  create a custom action that detects such per-user 
>> installation and asks user to uninstall first.
>>
>>
>>
>> -Original Message-
>> From: Derek Wickern [mailto:dwick...@gmail.com]
>> Sent: Wednesday, November 28, 2012 02:51
>> To: wix-users@lists.sourceforge.net
>> Subject: [WiX-users] WiX 3.6 upgrading perUser to perMachine
>>
>> I need to upgrade a package which was unfortunately created with 
>> per-user scope. It's installing to ProgramFiles. I understand that 
>> MSI can't upgrade my perUser to perMachine.
>>
>> I have some ideas:
>> 1. Automatically uninstall the per-user package (custom action?) 2.
>> Install
>> the per-machine package right on top of the per-user package 3. 
>> Detect the scope of the original package and upgrade to the same 
>> scope. Otherwise default to perMachine.
>>
>> I just upgraded my project to WiX 3.6 and I'm using burn to create a 
>> boostrapper. I'm hoping that gives me more options.
>>
>> What's the best solution here?
>>
>> -
>> - Keep yourself connected to Go Parallel:
>> INSIGHTS What's next for parallel hardware, programming and related 
>> areas?
>> Interviews and blogs by thought leaders keep you ahead of the curve.
>> http://goparallel.sourceforge.net
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>> -
>> - Keep yourself connected to Go Parallel:
>> INSIGHTS What's next for parallel hardware, programming and related 
>> areas?
>> Interviews and blogs by thought leaders keep you ahead of the curve.
>> http://goparallel.sourceforge.net
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>
>
> --
> Derek Wickern
>


--
Derek Wickern

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely 
access PCs and mobile devices and provide instant support Improve your 
efficiency, and focus on deliveri

Re: [WiX-users] WiX 3.6 upgrading perUser to perMachine

2012-12-18 Thread Neil Sleightholm

I had a vaguely similar problem; I had to remove and existing installation that 
didn't work in a way that was compatible with burn. To solve I wrote some code 
(a console app) to uninstall the old code and clean up and then just scheduled 
it with burn, I was able to detect that it hadn't run by looking for a file. 
May be you could do something similar.

Neil

-Original Message-
From: Derek Wickern [mailto:dwick...@gmail.com] 
Sent: 18 December 2012 19:09
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WiX 3.6 upgrading perUser to perMachine

I would really appreciate some help with this. As it is, I can't upgrade to 
Burn because the installer no longer has privileges to write to ProgramFiles in 
per-user mode.

I found this post from 2009:

http://stackoverflow.com/a/678190
>Sadly, the Windows Installer doesn't support that. Some process outside your 
>package (a bootstrapper/chainer?) will have to manage the upgrade from 
>per-user to per-machine.

Now there is an official bootstrapper. How can I best use it to upgrade 
per-user to per-machine?

On 11/28/12, Derek Wickern  wrote:
> It looks like I can use MsiEnumRelatedProducts to find the existing 
> products by upgrade code. I can't uninstall the old products from a 
> custom action, but I should be able to use the bootstrapper for that.
> I know there will be difficulty uninstalling a product which was 
> installed by another user, but I don't think I can solve that. I'm 
> just hoping to achieve a smooth upgrade path for most users.
>
> What's the best way to run my custom code from burn? Should I write a 
> managed bootstrapper application?
>
> On 11/27/12, Philip Patrick  wrote:
>> Well, not sure ours was the best solution, but what we did is a 
>> custom action that literally moves all registry entries related to 
>> per-user package to per-machine. That means from 
>> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\SID
>> -OF-USER to UserData\S-1-5-18 (latter stores per-machine 
>> installations).
>>
>> We decided to go this way because:
>> 1. It is not possible to uninstall another MSI from custom action 
>> since Windows Installer doesn't allow concurrent installations 2. 
>> Per-user installation could have been installed with different user 
>> than the one performing upgrade - this way MSI  will not "see" that 
>> there is something installed. At least we saw this behavior from our 
>> investigations.
>>
>> Today, I wouldn't recommend going this way - it is too buggy. Instead 
>> I would  create a custom action that detects such per-user 
>> installation and asks user to uninstall first.
>>
>>
>>
>> -Original Message-
>> From: Derek Wickern [mailto:dwick...@gmail.com]
>> Sent: Wednesday, November 28, 2012 02:51
>> To: wix-users@lists.sourceforge.net
>> Subject: [WiX-users] WiX 3.6 upgrading perUser to perMachine
>>
>> I need to upgrade a package which was unfortunately created with 
>> per-user scope. It's installing to ProgramFiles. I understand that 
>> MSI can't upgrade my perUser to perMachine.
>>
>> I have some ideas:
>> 1. Automatically uninstall the per-user package (custom action?) 2.
>> Install
>> the per-machine package right on top of the per-user package 3. 
>> Detect the scope of the original package and upgrade to the same 
>> scope. Otherwise default to perMachine.
>>
>> I just upgraded my project to WiX 3.6 and I'm using burn to create a 
>> boostrapper. I'm hoping that gives me more options.
>>
>> What's the best solution here?
>>
>> -
>> - Keep yourself connected to Go Parallel:
>> INSIGHTS What's next for parallel hardware, programming and related 
>> areas?
>> Interviews and blogs by thought leaders keep you ahead of the curve.
>> http://goparallel.sourceforge.net
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>> -
>> - Keep yourself connected to Go Parallel:
>> INSIGHTS What's next for parallel hardware, programming and related 
>> areas?
>> Interviews and blogs by thought leaders keep you ahead of the curve.
>> http://goparallel.sourceforge.net
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>
>
> --
> Derek Wickern
>


--
Derek Wickern

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely 
access PCs and mobile devices and provide instant support Improve your 
efficiency, and focus on delivering more value-add services Discover what IT 
Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d

Re: [WiX-users] odd behaviour in execution of a generated MSI

2012-12-18 Thread Phil Wilson

The issue appears to be this from the log:

=
Product registered: entering maintenance mode
Determined that existing product (either this product or the product being
upgraded with a patch) is installed per-machine.
==

..meaning that the same product is being installed again, going into
maintenance mode, the result of which depends on if you have maintence mode
dialogs etc. It will not install the same product (as defined by ProductCode
or PackageCode) twice.

Phil  

-Original Message-
From: Gilles Crebassa [mailto:crebassa.gil...@gmail.com] 
Sent: Monday, December 17, 2012 10:48 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] odd behaviour in execution of a generated MSI

Here find the content of files:
 MSI_NOT_OK.log ==
=== Verbose logging started: 5/12/2012  16:06:02  Build type: SHIP UNICODE
5.00.7600.00  Calling process: C:\WINDOWS\system32\msiexec.exe ===
Font created.  Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell
Dlg

Font created.  Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell
Dlg

Resetting cached policy values
Machine policy value 'Debug' is 0
*** RunEngine:
   *** Product: zSOPRA_Custom_Actions.1.5.0.0.msi
   *** Action:
   *** CommandLine: **
Machine policy value 'DisableUserInstalls' is 0
Cloaking enabled.
Attempting to enable all disabled privileges before calling Install on
Server
End dialog not enabled
Original package ==> C:\TEMP\zSOPRA_Custom_Actions.1.5.0.0.msi
Package we're running from ==> C:\WINDOWS\Installer\e218de80.msi
APPCOMPAT: Uninstall Flags override found.
APPCOMPAT: Uninstall VersionNT override found.
APPCOMPAT: Uninstall ServicePackLevel override found.
APPCOMPAT: looking for appcompat database entry with ProductCode
'{8570C613-A0C5-435F-9224-C795B285385F}'.
APPCOMPAT: no matching ProductCode found in database.
MSCOREE not loaded loading copy from system32
Machine policy value 'DisablePatch' is 0
Machine policy value 'AllowLockdownPatch' is 0
Machine policy value 'DisableLUAPatching' is 0
Machine policy value 'DisableFlyWeightPatching' is 0
APPCOMPAT: looking for appcompat database entry with ProductCode
'{8570C613-A0C5-435F-9224-C795B285385F}'.
APPCOMPAT: no matching ProductCode found in database.
Transforms are not secure.
Note: 1: 2205 2:  3: Control
PROPERTY CHANGE: Adding MsiLogFileLocation property. Its value is
'C:\TEMP\logmsi.log'.
Command Line: CURRENTDIRECTORY=C:\TEMP CLIENTUILEVEL=0 CLIENTPROCESSID=4648
PROPERTY CHANGE: Adding PackageCode property. Its value is
'{40D508B6-F92E-4FD7-B5C0-B22C8F6A8526}'.
Product Code passed to Engine.Initialize:
'{8570C613-A0C5-435F-9224-C795B285385F}'
Product Code from property table before transforms:
'{8570C613-A0C5-435F-9224-C795B285385F}'
Product Code from property table after transforms:
 '{8570C613-A0C5-435F-9224-C795B285385F}'
Product registered: entering maintenance mode
Determined that existing product (either this product or the product being
upgraded with a patch) is installed per-machine.
PROPERTY CHANGE: Adding ALLUSERS property. Its value is '1'.
PROPERTY CHANGE: Adding ProductState property. Its value is '5'.
PROPERTY CHANGE: Adding ProductToBeRegistered property. Its value is '1'.
Note: 1: 1402 2:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explore
r
3: 2
Entering CMsiConfigurationManager::SetLastUsedSource.
Specifed source is not already in a list.
User policy value 'SearchOrder' is 'nmu'
Machine policy value 'DisableBrowse' is 0
Machine policy value 'AllowLockdownBrowse' is 0
Adding new sources is allowed.
Package name retrieved from configuration data:
'zSOPRA_Custom_Actions.1.5.0.0.msi'
Note: 1: 2205 2:  3: Error
Note: 1: 2262 2: AdminProperties 3: -2147287038
Machine policy value 'DisableMsi' is 0
Machine policy value 'AlwaysInstallElevated' is 0
User policy value 'AlwaysInstallElevated' is 0
Product {8570C613-A0C5-435F-9224-C795B285385F} is admin assigned:
LocalSystem owns the publish key.
Product {8570C613-A0C5-435F-9224-C795B285385F} is managed.
Running product '{8570C613-A0C5-435F-9224-C795B285385F}' with elevated
privileges: Product is assigned.
PROPERTY CHANGE: Adding CURRENTDIRECTORY property. Its value is 'C:\TEMP'.
PROPERTY CHANGE: Adding CLIENTUILEVEL property. Its value is '0'.
PROPERTY CHANGE: Adding CLIENTPROCESSID property. Its value is '4648'.
PROPERTY CHANGE: Adding MsiSystemRebootPending property. Its value is '1'.
TRANSFORMS property is now:
PROPERTY CHANGE: Adding PRODUCTLANGUAGE property. Its value is '1033'.
PROPERTY CHANGE: Adding VersionDatabase property. Its value is '200'.
SHELL32::SHGetFolderPath returned: C:\Users\_pwillems\AppData\Roaming
SHELL32::SHGetFolderPath returned: C:\Users\_pwillems\Favorites
SHELL32::SHGetFolderPath returned:
C:\Users\_pwillems\AppData\Roaming\Microsoft\Windows\Network Shortcuts
SHELL32::SHGetFolderPath returned: C:\Us

Re: [WiX-users] Propogating Environmnet variables

2012-12-18 Thread Chad Petersen

That Windows for you. Existing CMD consoles don't get updated environment 
variables. Happens with no installer involved, too. For example, open a CMD 
Prompt. Then go to your Environment variables and alter your Path. The altered 
Path won't show up in the running CMD Prompt, but new CMD Prompts will show the 
altered path.

It's worked like this as long as I can remember. I don't believe an installer 
can overcome these Windows limitations, if you will.

-Original Message-
From: Mita Patel [mailto:mpa...@esri.com] 
Sent: Monday, December 17, 2012 4:31 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Propogating Environmnet variables

We are having issues propagating the environment variables. The setup has a 
custom action that propagates the environment using  the SendMessageTimeOut api

  SendMessageTimeout(HWND_BROADCAST, WM_SETTINGCHANGE, 0,(LPARAM) 
"Environment", SMTO_ABORTIFHUNG, 5000, NULL);

On a 64 bit OS, both 32 and 64 bit consoles were opened before the install.  
Ran the install with the above custom action. If a console window is open one 
doesn't see the custom Environment.  But open a new console session and the 
varaible is listed (for both 32 and 64 bit cosole).  Is this the correct 
behavior?  Is there a way for the console window opened before the install to 
see the custom environment variable.

Thanks
Mita

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely 
access PCs and mobile devices and provide instant support Improve your 
efficiency, and focus on delivering more value-add services Discover what IT 
Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX 3.6 upgrading perUser to perMachine

2012-12-18 Thread Derek Wickern

I would really appreciate some help with this. As it is, I can't
upgrade to Burn because the installer no longer has privileges to
write to ProgramFiles in per-user mode.

I found this post from 2009:

http://stackoverflow.com/a/678190
>Sadly, the Windows Installer doesn't support that. Some process outside your 
>package (a bootstrapper/chainer?) will have to manage the upgrade from 
>per-user to per-machine.

Now there is an official bootstrapper. How can I best use it to
upgrade per-user to per-machine?

On 11/28/12, Derek Wickern  wrote:
> It looks like I can use MsiEnumRelatedProducts to find the existing
> products by upgrade code. I can't uninstall the old products from a
> custom action, but I should be able to use the bootstrapper for that.
> I know there will be difficulty uninstalling a product which was
> installed by another user, but I don't think I can solve that. I'm
> just hoping to achieve a smooth upgrade path for most users.
>
> What's the best way to run my custom code from burn? Should I write a
> managed bootstrapper application?
>
> On 11/27/12, Philip Patrick  wrote:
>> Well, not sure ours was the best solution, but what we did is a custom
>> action that literally moves all registry entries related to per-user
>> package
>> to per-machine. That means from
>> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\SID-OF-USER
>> to UserData\S-1-5-18 (latter stores per-machine installations).
>>
>> We decided to go this way because:
>> 1. It is not possible to uninstall another MSI from custom action since
>> Windows Installer doesn't allow concurrent installations
>> 2. Per-user installation could have been installed with different user
>> than
>> the one performing upgrade - this way MSI  will not "see" that there is
>> something installed. At least we saw this behavior from our
>> investigations.
>>
>> Today, I wouldn't recommend going this way - it is too buggy. Instead I
>> would  create a custom action that detects such per-user installation and
>> asks user to uninstall first.
>>
>>
>>
>> -Original Message-
>> From: Derek Wickern [mailto:dwick...@gmail.com]
>> Sent: Wednesday, November 28, 2012 02:51
>> To: wix-users@lists.sourceforge.net
>> Subject: [WiX-users] WiX 3.6 upgrading perUser to perMachine
>>
>> I need to upgrade a package which was unfortunately created with per-user
>> scope. It's installing to ProgramFiles. I understand that MSI can't
>> upgrade
>> my perUser to perMachine.
>>
>> I have some ideas:
>> 1. Automatically uninstall the per-user package (custom action?) 2.
>> Install
>> the per-machine package right on top of the per-user package 3. Detect
>> the
>> scope of the original package and upgrade to the same scope. Otherwise
>> default to perMachine.
>>
>> I just upgraded my project to WiX 3.6 and I'm using burn to create a
>> boostrapper. I'm hoping that gives me more options.
>>
>> What's the best solution here?
>>
>> --
>> Keep yourself connected to Go Parallel:
>> INSIGHTS What's next for parallel hardware, programming and related
>> areas?
>> Interviews and blogs by thought leaders keep you ahead of the curve.
>> http://goparallel.sourceforge.net
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>> --
>> Keep yourself connected to Go Parallel:
>> INSIGHTS What's next for parallel hardware, programming and related
>> areas?
>> Interviews and blogs by thought leaders keep you ahead of the curve.
>> http://goparallel.sourceforge.net
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>
>
> --
> Derek Wickern
>


-- 
Derek Wickern

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WixMbaPrereqPackageId variable not visible from Fragment element

2012-12-18 Thread Mihajlo Cvetanović

I had those two lines already, but like I said they were in Fragment element
instead of in Bundle element. When I moved them to Bundle element the
problem was gone. My question is if this is requirement or a bug? Do
WixVariable elements must reside in Bundle element?



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WixMbaPrereqPackageId-variable-not-visible-from-Fragment-element-tp7582403p7582435.html
Sent from the wix-users mailing list archive at Nabble.com.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Using WIX with the new ETL EventSource mechanisms...

2012-12-18 Thread Thomas Tomiczek

...for .NET 4.5. Anyone has a more detailed walkthrough?

I am trying to figure out the nw tracingmechanism for a windows service we 
distribute to various computer as a HPC cluster (so they do processing jobs in 
the background). I would love to use ETC:

I have created a tracing class in a separate dll, now I try to get WIX to 
register it properly but it does not show up.

My code so far is:


  
  


The problem is that when I use

Logman query providers

There is no Reflexo related agent installed at all, so I think something goes 
wrong there. There is no error showing up anywhere, and install/uninstall 
nicely adds/removes the log (Reflexo.Agent).

Am I misunderstanding something? I think I should also register the event 
source, but - well - I fail to find a WIX tag for that.

Regards

Thomas
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Condition a Merge module to be installed or skipped

Re: [WiX-users] Registry search and condition message in installer

Re: [WiX-users] Registry search and condition message in installer

[WiX-users] Condition a Merge module to be installed or skipped

Re: [WiX-users] Registry search and condition message in installer

Re: [WiX-users] Are "*" Component Guids trustworthy (for IIS subdirectory)?

[WiX-users] Registry search and condition message in installer

[WiX-users] Are "*" Component Guids trustworthy (for IIS subdirectory)?

Re: [WiX-users] Error 0x80070643: Failed to install MSI package.

Re: [WiX-users] Error 0x80070643: Failed to install MSI package.

[WiX-users] Error 0x80070643: Failed to install MSI package.

Re: [WiX-users] WiX 3.6 upgrading perUser to perMachine

Re: [WiX-users] WiX 3.6 upgrading perUser to perMachine

Re: [WiX-users] odd behaviour in execution of a generated MSI

Re: [WiX-users] Propogating Environmnet variables

Re: [WiX-users] WiX 3.6 upgrading perUser to perMachine

Re: [WiX-users] WixMbaPrereqPackageId variable not visible from Fragment element

[WiX-users] Using WIX with the new ETL EventSource mechanisms...

18 matches

Site Navigation

Mail list logo

Footer information