Re: [WiX-users] UI upgrade succeeds, but silent upgrade fails
Thank you for clarifying this for me, Peter!
I ran the MSI without REINSTALL and REINSTALLMODE and it worked like a charm!
Your explanation was perfect and Rob's response provided further
clarifications on this page
http://stackoverflow.com/questions/526707/major-vs-minor-upgrade-in-windows-installer
Thanks,
Alec
On Fri, Sep 21, 2012 at 3:04 AM, Peter Shirtcliffe pshirtcli...@sdl.com wrote:
Are you mixing up minor and major upgrades ?
Major upgrades use the upgrade table and replace the old product with the new
one. You don't specify REINSTALL or REINSTALLMODE on the command line. The
upgrade code should be the same and the product code and version different.
Minor upgrades repair and update the existing installation using a new
version of the MSI. You do use REINSTALL and REINSTALLMODE but the upgrade
table is not used. The upgrade code should be the same and the product code
too: only the version differs.
The MajorUpgrade element is just a convenient shorthand for using the upgrade
table. You can leave it commented out for now.
-Original Message-
From: Alec [mailto:alecs...@gmail.com]
Sent: 21 September 2012 04:30
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] UI upgrade succeeds, but silent upgrade fails
I tried silently upgrading 19.0.1 on top of 18.3 with the following code
snippet:
Upgrade Id=E8805AF3-CF50-4092-BE57-220A8C51E2AA
UpgradeVersion OnlyDetect=yes Minimum=19.0.1
IncludeMinimum=no Property=NEWERVERSIONDETECTED/ UpgradeVersion
OnlyDetect=no Maximum=19.0.1 IncludeMaximum=no
Minimum=18.0.0 IncludeMinimum=yes
Property=OLDERVERSIONBEINGUPGRADED/
/Upgrade
CustomActionRef Id=WixExitEarlyWithSuccess/
InstallExecuteSequence
RemoveExistingProducts After=InstallInitialize/
Custom Action='PrepareForInstall' After='InstallInitialize'NOT Installed
AND NOT UPGRADINGPRODUCTCODE/Custom
Custom Action='SetJavawPath' Before='InstallServices'NOT
Installed/Custom
Custom Action=Upgrader After=InstallHelperActionNOT
Installed/Custom /InstallExecuteSequence
The log file has the following entries:
Doing action: FindRelatedProducts
Action start 12:01:15: FindRelatedProducts.
PROPERTY CHANGE: Adding OLDERVERSIONBEINGUPGRADED property. Its value is
'{4B43BAEB-553B-4FAD-9219-C55DA3492D89}'.
Skipping action: WixExitEarlyWithSuccess (condition is false)
Doing action: AppSearch
FindRelatedProducts. Return value 1.
AppSearch.
...
Windows Installer installed the product. ... Product Version:
19.0.1. Product Language: 1033. .. Installation success or error
status: 0.
It looks like upgrade should have succeeded, but in reality 18.3 is there and
19.0.1 is not.
I noticed that we have MajorUpgrade element commented out (see above).
Should it be uncommented? (Sorry I don't work with WIX a whole lot).
Thanks,
Alec
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/UI-upgrade-succ
eeds-but-silent-upgrade-fails-tp7580671p7580716.html
Sent from the wix-users mailing list archive at Nabble.com.
-
-
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
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.
--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
Re: [WiX-users] UI upgrade succeeds, but silent upgrade fails
I tried silently upgrading 19.0.1 on top of 18.3 with the following
code snippet:
Upgrade Id=E8805AF3-CF50-4092-BE57-220A8C51E2AA
UpgradeVersion OnlyDetect=yes Minimum=19.0.1
IncludeMinimum=no Property=NEWERVERSIONDETECTED/
UpgradeVersion OnlyDetect=no Maximum=19.0.1 IncludeMaximum=no
Minimum=18.0.0 IncludeMinimum=yes
Property=OLDERVERSIONBEINGUPGRADED/
/Upgrade
!--MajorUpgrade Schedule=afterInstallInitialize
AllowSameVersionUpgrades=yes/--
CustomActionRef Id=WixExitEarlyWithSuccess/
InstallExecuteSequence
RemoveExistingProducts After=InstallInitialize/
!-- These are our custom actions --
Custom Action='PrepareForInstall' After='InstallInitialize'NOT
Installed AND NOT UPGRADINGPRODUCTCODE/Custom
Custom Action='SetJavawPath' Before='InstallServices'NOT Installed/Custom
Custom Action=Upgrader After=InstallHelperActionNOT Installed/Custom
/InstallExecuteSequence
The log file has the following entries:
Doing action: FindRelatedProducts
Action start 12:01:15: FindRelatedProducts.
PROPERTY CHANGE: Adding OLDERVERSIONBEINGUPGRADED property. Its
value is '{4B43BAEB-553B-4FAD-9219-C55DA3492D89}'.
Skipping action: WixExitEarlyWithSuccess (condition is false)
Doing action: AppSearch
FindRelatedProducts. Return value 1.
AppSearch.
...
Windows Installer installed the product. ... Product Version:
19.0.1. Product Language: 1033. .. Installation success or error
status: 0.
It looks like upgrade should have succeeded, but in reality 18.3 is
there and 19.0.1 is not.
I noticed that we have MajorUpgrade element commented out (see
above). Should it be uncommented? (Sorry I don't work with WIX a whole
lot).
Thanks,
Alec
On Thu, Sep 20, 2012 at 3:15 AM, Peter Shirtcliffe pshirtcli...@sdl.com wrote:
One caveat if you follow Neil's advice. WixExitEarlyWithSuccess doesn't work
completely seamlessly with MajorUpgrade. See
http://sourceforge.net/p/wix/feature-requests/626/
The workaround is to schedule the CA yourself with this condition in the
install sequences:
Custom Action=WixExitEarlyWithSuccess
After=FindRelatedProductsWIX_DOWNGRADE_DETECTED/Custom
-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: 19 September 2012 22:29
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] UI upgrade succeeds, but silent upgrade fails
You might want to look at the MajorUpgrade element
http://wix.sourceforge.net/manual-wix3/major_upgrade.htm it makes it easier
to implement upgrades.
Neil
-Original Message-
From: Alec [mailto:alecs...@gmail.com]
Sent: 19 September 2012 22:12
To: wix-users@lists.sourceforge.net
Subject: -SPAM- Re: [WiX-users] UI upgrade succeeds, but silent
upgrade fails
I took that Upgrade snippet from Rob's answer on
http://stackoverflow.com/a/724098.
Let me try this with Minimum set.
Thanks,
Alec
On Wed, Sep 19, 2012 at 3:09 PM, Hoover, Jacob [via Windows Installer XML
(WiX) toolset] ml-node+s687559n7580675...@n2.nabble.com wrote:
Hmm, I think you are missing a minimum on OlderVerionBeingUpgraded
!-- This information enables Windows Installer major upgrade
functionality so users can seamlessly --
!-- install a new version of the product and have the old version
automatically uninstall behind--
!-- the scenes. See the following topic in the MSDN Library for
additional information: --
!--
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/s
etup/major_upgrades.asp
--
Upgrade Id=$(var.UpgradeCode)
UpgradeVersion Minimum=$(var.ProductVersion) IncludeMinimum=no
OnlyDetect=yes Property=NEWERVERSION_INSTALLED /
UpgradeVersion Minimum=0.0.0 IncludeMinimum=yes
Maximum=$(var.ProductVersion) IncludeMaximum=no
Property=OLDERVERSION_BEINGUPGRADED
MigrateFeatures=yes /
/Upgrade
As far as App Compat, I was talking in the logs.
In you logs, it looks as if your ProductCode hasn't changed between the
two?
(The product code should only be the same if you are doing a minor
update.)
-Original Message-
From: Alec Swan [mailto:[hidden email]]
Sent: Wednesday, September 19, 2012 3:57 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] UI upgrade succeeds, but silent upgrade fails
We are trying to upgrade from 18.3 to 19.0.1.
Here is the upgrade code:
Upgrade Id=E8805AF3-CF50-4092-BE57-220A8C51E2AA
UpgradeVersion OnlyDetect=no Minimum=18.0.1 IncludeMinimum=no
Property=NEWERVERSIONDETECTED/
UpgradeVersion OnlyDetect=no Maximum=19.0.1 IncludeMaximum=no
Property=OLDERVERSIONBEINGUPGRADED/
/Upgrade
How do we ignore APPCOMPAT? Do you need any other info?
Thanks,
Alec
On Wed, Sep 19, 2012 at 2:50 PM, Hoover, Jacob [hidden email] wrote:
Ignore the APPCOMPAT.
What does your Upgrade table look like? What are the versions of the
old and new MSI?
-Original
[WiX-users] UI upgrade succeeds, but silent upgrade fails
Hello,
We are testing upgrade from an older version to the version we are
about to release. We noticed that upgrading msiexec.exe /i my.msi
successfully upgrades the old product files with the new ones.
However, silently installing with the following command fails:
msiexec.exe /i my.msi REINSTALL=ALL REINSTALLMODE=vomus /qn
The log file generated during silent upgrade contains the following messages:
APPCOMPAT: looking for appcompat database entry with ProductCode
'{15E9E02D-8660-41B3-9373-3E427A392478}'.
APPCOMPAT: no matching ProductCode found in database.
..
FindRelatedProducts.
PROPERTY CHANGE: Adding OLDERVERSIONBEINGUPGRADED property. Its value
is '{4B43BAEB-553B-4FAD-9219-C55DA3492D89}'.
PROPERTY CHANGE: Adding NEWERVERSIONDETECTED property. Its value is
'{4B43BAEB-553B-4FAD-9219-C55DA3492D89}'.
Doing action: WixExitEarlyWithSuccess
FindRelatedProducts. Return value 1.
Does this mean that installer is not finding the previous product
version and hence doesn't uninstall it? If so, why would UI upgrade
work?
I also noticed that we didn't have Package Id specified in the WXS
file for the old product. However, we did specify the same Product
UpgradeCode in the old and new versions. Is this sufficient?
Thanks,
Alec
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] UI upgrade succeeds, but silent upgrade fails
We are trying to upgrade from 18.3 to 19.0.1.
Here is the upgrade code:
Upgrade Id=E8805AF3-CF50-4092-BE57-220A8C51E2AA
UpgradeVersion OnlyDetect=no Minimum=18.0.1 IncludeMinimum=no
Property=NEWERVERSIONDETECTED/
UpgradeVersion OnlyDetect=no Maximum=19.0.1 IncludeMaximum=no
Property=OLDERVERSIONBEINGUPGRADED/
/Upgrade
How do we ignore APPCOMPAT? Do you need any other info?
Thanks,
Alec
On Wed, Sep 19, 2012 at 2:50 PM, Hoover, Jacob
jacob.hoo...@greenheck.com wrote:
Ignore the APPCOMPAT.
What does your Upgrade table look like? What are the versions of the old and
new MSI?
-Original Message-
From: Alec Swan [mailto:alecs...@gmail.com]
Sent: Wednesday, September 19, 2012 2:49 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] UI upgrade succeeds, but silent upgrade fails
Hello,
We are testing upgrade from an older version to the version we are about to
release. We noticed that upgrading msiexec.exe /i my.msi
successfully upgrades the old product files with the new ones.
However, silently installing with the following command fails:
msiexec.exe /i my.msi REINSTALL=ALL REINSTALLMODE=vomus /qn
The log file generated during silent upgrade contains the following messages:
APPCOMPAT: looking for appcompat database entry with ProductCode
'{15E9E02D-8660-41B3-9373-3E427A392478}'.
APPCOMPAT: no matching ProductCode found in database.
..
FindRelatedProducts.
PROPERTY CHANGE: Adding OLDERVERSIONBEINGUPGRADED property. Its value is
'{4B43BAEB-553B-4FAD-9219-C55DA3492D89}'.
PROPERTY CHANGE: Adding NEWERVERSIONDETECTED property. Its value is
'{4B43BAEB-553B-4FAD-9219-C55DA3492D89}'.
Doing action: WixExitEarlyWithSuccess
FindRelatedProducts. Return value 1.
Does this mean that installer is not finding the previous product version and
hence doesn't uninstall it? If so, why would UI upgrade work?
I also noticed that we didn't have Package Id specified in the WXS file for
the old product. However, we did specify the same Product UpgradeCode in the
old and new versions. Is this sufficient?
Thanks,
Alec
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will
include endpoint security, mobile security and the latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] UnistallString is not written in Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key
We use UninstallString to run the uninstaller when the product is updated in place. So, when the user runs our installer the installer looks for UninstallString reg key and if found the installer asks if user wants to wipe out previous product version's data or try to preserve it and then runs the uninstaller passing user's answer as a command-line parameter. Are we doing this wrong? How else can we find the path to the uninstaller of the product version installed on user's machine? Thanks, Alec On Thu, Aug 23, 2012 at 3:17 AM, Peter Shirtcliffe pshirtcli...@sdl.com wrote: Windows Installer itself writes the value. http://msdn.microsoft.com/en-us/library/aa372105%28v=VS.85%29.aspx However, the uninstall string is not used by Windows Installer so does it matter that it wasn't written ? -Original Message- From: Alec Swan [mailto:alecs...@gmail.com] Sent: 23 August 2012 00:23 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] UnistallString is not written in Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key Hello, I am trying to track down why our installer generated using Wix 3.0 stopped writing the UninstallString value in Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key. At some point we must have changed some code that broke this behavior. Where should I start troubleshooting this? Which Wix action writes this registry key? Thanks, Alec - - Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ 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. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] UnistallString is not written in Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key
We can still uninstall the product from Add/Remove Programs but there is no entry for our product under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall reg key. Is it possible UninstallString is written in some other registry location? Thanks, Alec On Thu, Aug 23, 2012 at 9:06 AM, Peter Shirtcliffe pshirtcli...@sdl.com wrote: Sounds like an strange design. Normally you'd make a major upgrade to remove the old version automatically and replace it with the new one. Any data that needs preserving is probably configuration or user data and should be handled by the application rather than the installer. The normal way to uninstall is via Add/Remove Programs (Programs And Features) but you can make a shortcut as shown in http://robmensching.com/blog/posts/2007/4/27/How-to-create-an-uninstall-short cut-and-pass-all-the Have you set ARPNOREMOVE ? That would suppress the uninstall string. -Original Message- From: Alec Swan [mailto:alecs...@gmail.com] Sent: 23 August 2012 15:22 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] UnistallString is not written in Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key We use UninstallString to run the uninstaller when the product is updated in place. So, when the user runs our installer the installer looks for UninstallString reg key and if found the installer asks if user wants to wipe out previous product version's data or try to preserve it and then runs the uninstaller passing user's answer as a command-line parameter. Are we doing this wrong? How else can we find the path to the uninstaller of the product version installed on user's machine? Thanks, Alec On Thu, Aug 23, 2012 at 3:17 AM, Peter Shirtcliffe pshirtcli...@sdl.com wrote: Windows Installer itself writes the value. http://msdn.microsoft.com/en-us/library/aa372105%28v=VS.85%29.aspx However, the uninstall string is not used by Windows Installer so does it matter that it wasn't written ? -Original Message- From: Alec Swan [mailto:alecs...@gmail.com] Sent: 23 August 2012 00:23 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] UnistallString is not written in Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key Hello, I am trying to track down why our installer generated using Wix 3.0 stopped writing the UninstallString value in Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key. At some point we must have changed some code that broke this behavior. Where should I start troubleshooting this? Which Wix action writes this registry key? Thanks, Alec -- --- - Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ 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. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - - Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat
Re: [WiX-users] UnistallString is not written in Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key
Actually, I just found that
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{5D6E0940-C1EB-4C60-8A36-54D6BCCF5C02}
contains an UninstallString for our product. Now I have to track down
how we ended up with a GUID in this reg key because it used to be the
name of our product.
I am new to all this and appreciate any help with this.
Thanks,
Alec
On Thu, Aug 23, 2012 at 9:27 AM, Alec Swan alecs...@gmail.com wrote:
We can still uninstall the product from Add/Remove Programs but there
is no entry for our product under
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall
reg key. Is it possible UninstallString is written in some other
registry location?
Thanks,
Alec
On Thu, Aug 23, 2012 at 9:06 AM, Peter Shirtcliffe pshirtcli...@sdl.com
wrote:
Sounds like an strange design. Normally you'd make a major upgrade to remove
the old version automatically and replace it with the new one. Any data that
needs preserving is probably configuration or user data and should be handled
by the application rather than the installer. The normal way to uninstall is
via Add/Remove Programs (Programs And Features) but you can make a shortcut
as shown in
http://robmensching.com/blog/posts/2007/4/27/How-to-create-an-uninstall-short
cut-and-pass-all-the
Have you set ARPNOREMOVE ? That would suppress the uninstall string.
-Original Message-
From: Alec Swan [mailto:alecs...@gmail.com]
Sent: 23 August 2012 15:22
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] UnistallString is not written in
Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key
We use UninstallString to run the uninstaller when the product is updated in
place.
So, when the user runs our installer the installer looks for UninstallString
reg key and if found the installer asks if user wants to wipe out previous
product version's data or try to preserve it and then runs the uninstaller
passing user's answer as a command-line parameter.
Are we doing this wrong? How else can we find the path to the uninstaller of
the product version installed on user's machine?
Thanks,
Alec
On Thu, Aug 23, 2012 at 3:17 AM, Peter Shirtcliffe pshirtcli...@sdl.com
wrote:
Windows Installer itself writes the value.
http://msdn.microsoft.com/en-us/library/aa372105%28v=VS.85%29.aspx
However, the uninstall string is not used by Windows Installer so does
it matter that it wasn't written ?
-Original Message-
From: Alec Swan [mailto:alecs...@gmail.com]
Sent: 23 August 2012 00:23
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] UnistallString is not written in
Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key
Hello,
I am trying to track down why our installer generated using Wix 3.0
stopped writing the UninstallString value in
Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key. At
some point we must have changed some code that broke this behavior.
Where should I start troubleshooting this? Which Wix action writes
this registry key?
Thanks,
Alec
--
---
-
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond.
Discussions will include endpoint security, mobile security and the latest
in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
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.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond.
Discussions will include endpoint security, mobile security and the
latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-
-
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will
include endpoint security, mobile
[WiX-users] [CLOSED]: UnistallString is not written in Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key
After some internal discussions it turned out that we were looking for
UnistallString to support upgrade from our product version that used
to be installed with NullSoft to the version that is currently
installed with MSI.
I am closing this thread, sorry for the confusion.
Thanks,
Alec
On Thu, Aug 23, 2012 at 9:33 AM, Alec Swan alecs...@gmail.com wrote:
Actually, I just found that
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{5D6E0940-C1EB-4C60-8A36-54D6BCCF5C02}
contains an UninstallString for our product. Now I have to track down
how we ended up with a GUID in this reg key because it used to be the
name of our product.
I am new to all this and appreciate any help with this.
Thanks,
Alec
On Thu, Aug 23, 2012 at 9:27 AM, Alec Swan alecs...@gmail.com wrote:
We can still uninstall the product from Add/Remove Programs but there
is no entry for our product under
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall
reg key. Is it possible UninstallString is written in some other
registry location?
Thanks,
Alec
On Thu, Aug 23, 2012 at 9:06 AM, Peter Shirtcliffe pshirtcli...@sdl.com
wrote:
Sounds like an strange design. Normally you'd make a major upgrade to remove
the old version automatically and replace it with the new one. Any data that
needs preserving is probably configuration or user data and should be
handled
by the application rather than the installer. The normal way to uninstall is
via Add/Remove Programs (Programs And Features) but you can make a shortcut
as shown in
http://robmensching.com/blog/posts/2007/4/27/How-to-create-an-uninstall-short
cut-and-pass-all-the
Have you set ARPNOREMOVE ? That would suppress the uninstall string.
-Original Message-
From: Alec Swan [mailto:alecs...@gmail.com]
Sent: 23 August 2012 15:22
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] UnistallString is not written in
Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key
We use UninstallString to run the uninstaller when the product is updated in
place.
So, when the user runs our installer the installer looks for UninstallString
reg key and if found the installer asks if user wants to wipe out previous
product version's data or try to preserve it and then runs the uninstaller
passing user's answer as a command-line parameter.
Are we doing this wrong? How else can we find the path to the uninstaller of
the product version installed on user's machine?
Thanks,
Alec
On Thu, Aug 23, 2012 at 3:17 AM, Peter Shirtcliffe pshirtcli...@sdl.com
wrote:
Windows Installer itself writes the value.
http://msdn.microsoft.com/en-us/library/aa372105%28v=VS.85%29.aspx
However, the uninstall string is not used by Windows Installer so does
it matter that it wasn't written ?
-Original Message-
From: Alec Swan [mailto:alecs...@gmail.com]
Sent: 23 August 2012 00:23
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] UnistallString is not written in
Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key
Hello,
I am trying to track down why our installer generated using Wix 3.0
stopped writing the UninstallString value in
Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key. At
some point we must have changed some code that broke this behavior.
Where should I start troubleshooting this? Which Wix action writes
this registry key?
Thanks,
Alec
--
---
-
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond.
Discussions will include endpoint security, mobile security and the latest
in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
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.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond.
Discussions will include endpoint security, mobile security and the
latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users
Re: [WiX-users] UnistallString is not written in Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key
You are spot on! We were using NullSoft product. I just closed the thread.
Thanks!
On Thu, Aug 23, 2012 at 9:55 AM, Peter Shirtcliffe pshirtcli...@sdl.com wrote:
An MSI installer will always have the product code GUID in the key, exactly
as you have there. Were you using InstallShield or something before ?
-Original Message-
From: Alec Swan [mailto:alecs...@gmail.com]
Sent: 23 August 2012 16:34
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] UnistallString is not written in
Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key
Actually, I just found that
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{5D6E0
940-C1EB-4C60-8A36-54D6BCCF5C02}
contains an UninstallString for our product. Now I have to track down how we
ended up with a GUID in this reg key because it used to be the name of our
product.
I am new to all this and appreciate any help with this.
Thanks,
Alec
On Thu, Aug 23, 2012 at 9:27 AM, Alec Swan alecs...@gmail.com wrote:
We can still uninstall the product from Add/Remove Programs but there
is no entry for our product under
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall
reg key. Is it possible UninstallString is written in some other
registry location?
Thanks,
Alec
On Thu, Aug 23, 2012 at 9:06 AM, Peter Shirtcliffe pshirtcli...@sdl.com
wrote:
Sounds like an strange design. Normally you'd make a major upgrade to
remove the old version automatically and replace it with the new one.
Any data that needs preserving is probably configuration or user data
and should be handled by the application rather than the installer.
The normal way to uninstall is via Add/Remove Programs (Programs And
Features) but you can make a shortcut as shown in
http://robmensching.com/blog/posts/2007/4/27/How-to-create-an-uninsta
ll-short
cut-and-pass-all-the
Have you set ARPNOREMOVE ? That would suppress the uninstall string.
-Original Message-
From: Alec Swan [mailto:alecs...@gmail.com]
Sent: 23 August 2012 15:22
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] UnistallString is not written in
Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key
We use UninstallString to run the uninstaller when the product is
updated in place.
So, when the user runs our installer the installer looks for
UninstallString reg key and if found the installer asks if user wants
to wipe out previous product version's data or try to preserve it and
then runs the uninstaller passing user's answer as a command-line
parameter.
Are we doing this wrong? How else can we find the path to the
uninstaller of the product version installed on user's machine?
Thanks,
Alec
On Thu, Aug 23, 2012 at 3:17 AM, Peter Shirtcliffe
pshirtcli...@sdl.com
wrote:
Windows Installer itself writes the value.
http://msdn.microsoft.com/en-us/library/aa372105%28v=VS.85%29.aspx
However, the uninstall string is not used by Windows Installer so
does it matter that it wasn't written ?
-Original Message-
From: Alec Swan [mailto:alecs...@gmail.com]
Sent: 23 August 2012 00:23
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] UnistallString is not written in
Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key
Hello,
I am trying to track down why our installer generated using Wix 3.0
stopped writing the UninstallString value in
Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key.
At some point we must have changed some code that broke this behavior.
Where should I start troubleshooting this? Which Wix action writes
this registry key?
Thanks,
Alec
--
---
-
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond.
Discussions will include endpoint security, mobile security and the
latest
in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
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.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond
[WiX-users] UnistallString is not written in Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key
Hello, I am trying to track down why our installer generated using Wix 3.0 stopped writing the UninstallString value in Software\Microsoft\Windows\CurrentVersion\Uninstall\ registry key. At some point we must have changed some code that broke this behavior. Where should I start troubleshooting this? Which Wix action writes this registry key? Thanks, Alec -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Setting MsiLogFileLocation property
Does anybody have sample code or pointers on how to pass parameters or
arguments to MsiProductInstall() in bootstrapper?
On Fri, Mar 16, 2012 at 10:55 AM, Alec Swan alecs...@gmail.com wrote:
session.Log seems to work fine, thanks. However, I can only see these
messages in the log file if I pass /l*v parameter to msiexec.
So, how do I write that bootstrapper that passes /l*v command line
parameter or an argument to MsiProductInstall() which enables logging?
Thanks,
Alec
On Fri, Mar 16, 2012 at 8:41 AM, Hoover, Jacob
jacob.hoo...@greenheck.com wrote:
For .Net CA's there is a Log method on the session object. As for C/C+
custom actions, the SDK provides a WcaLog(LOGMSG_STANDARD, Message goes
here.) method.
Both of these will write to the Windows installer log, if it's enabled.
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: Thursday, March 15, 2012 5:42 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Setting MsiLogFileLocation property
I use a second custom action called WriteToMSILog that I call at specific
times from my first custom action to log to the normal log file that
everything else writes to. Keeps everything in one log file and is easy to
call as needed.
The CDATA portion looks like this (Jscript example)
![CDATA[
try
{
var szMessage = Session.Property(
WriteToMSILog );
var msiMessageTypeInfo = 0x0400;//
Informative message for log, not to be displayed.
var sDelim =
;
//Create a record with only one field
var oRecord = Session.Installer.CreateRecord(
1 );
//Create the full message
szFullMessage = sDelim + \n + szMessage;
oRecord.StringData( 0 ) = [1];
oRecord.StringData( 1 ) = szFullMessage;
Session.FormatRecord( oRecord );
Session.Message( msiMessageTypeInfo, oRecord
);
oRecord = null;
}
catch(e)
{
}
]]
The call from my first custom action looks like this
Session.Property(WriteToMSILog) = Process Name: + pProps[proc];
Session.DoAction(WriteToMSILog);
-Original Message-
From: Alec Swan [mailto:alecs...@gmail.com]
Sent: Thursday, March 15, 2012 3:20 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Setting MsiLogFileLocation property
Wow, this is a pretty active mailing list. I think we have the
definite answer now.
As you can already tell I am a newbie to WIX, so please take it easy
on me with my next question. What logging mechanism do you normally
use to log messages from your custom actions?
Thanks,
Alec
On Thu, Mar 15, 2012 at 12:58 PM, Castro, Edwin G. (Hillsboro)
edwin.cas...@fiserv.com wrote:
In addition, the Windows Installer engine starts producing log messages
before it loads the MSI package to determine what log file to use.
In short, one can set a log file:
* On the command line
* As an argument to MsiProductInstall()
* In the registry (global and applies to all MSI packages, cannot be
changed on a per package basis)
The MsiLogFileLocation property is automatically set by the Windows
Installer engine to allow a MSI UI to display the log file location on a
dialog. Changing the value of MsiLogFileLocation within the MSI package
itself does not change where the Windows Installer engine is logging to (as
evidenced by the tests performed by various people).
To automatically set a log file you'll need to use a bootstrapper as was
already suggested so that the bootstrapper can set it on the command line
or as an argument to MsiProductInstall().
Your system administrator could use the registry approach to control
whether all MSI packages generate a log file to a specific folder location
with a random: MSI*.LOG name.
This is documented in the MSDN documentation so if anybody wants to use
this approach I suggest they check MSDN at
http://msdn.microsoft.com/en-us/library/windows/desktop/aa372847.aspx
Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: Thursday, March 15, 2012 11:22 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Setting MsiLogFileLocation property
A good test anyone can
Re: [WiX-users] Setting MsiLogFileLocation property
session.Log seems to work fine, thanks. However, I can only see these
messages in the log file if I pass /l*v parameter to msiexec.
So, how do I write that bootstrapper that passes /l*v command line
parameter or an argument to MsiProductInstall() which enables logging?
Thanks,
Alec
On Fri, Mar 16, 2012 at 8:41 AM, Hoover, Jacob
jacob.hoo...@greenheck.com wrote:
For .Net CA's there is a Log method on the session object. As for C/C+ custom
actions, the SDK provides a WcaLog(LOGMSG_STANDARD, Message goes here.)
method.
Both of these will write to the Windows installer log, if it's enabled.
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: Thursday, March 15, 2012 5:42 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Setting MsiLogFileLocation property
I use a second custom action called WriteToMSILog that I call at specific
times from my first custom action to log to the normal log file that
everything else writes to. Keeps everything in one log file and is easy to
call as needed.
The CDATA portion looks like this (Jscript example)
![CDATA[
try
{
var szMessage = Session.Property(
WriteToMSILog );
var msiMessageTypeInfo = 0x0400;//
Informative message for log, not to be displayed.
var sDelim =
;
//Create a record with only one field
var oRecord = Session.Installer.CreateRecord(
1 );
//Create the full message
szFullMessage = sDelim + \n + szMessage;
oRecord.StringData( 0 ) = [1];
oRecord.StringData( 1 ) = szFullMessage;
Session.FormatRecord( oRecord );
Session.Message( msiMessageTypeInfo, oRecord );
oRecord = null;
}
catch(e)
{
}
]]
The call from my first custom action looks like this
Session.Property(WriteToMSILog) = Process Name: + pProps[proc];
Session.DoAction(WriteToMSILog);
-Original Message-
From: Alec Swan [mailto:alecs...@gmail.com]
Sent: Thursday, March 15, 2012 3:20 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Setting MsiLogFileLocation property
Wow, this is a pretty active mailing list. I think we have the
definite answer now.
As you can already tell I am a newbie to WIX, so please take it easy
on me with my next question. What logging mechanism do you normally
use to log messages from your custom actions?
Thanks,
Alec
On Thu, Mar 15, 2012 at 12:58 PM, Castro, Edwin G. (Hillsboro)
edwin.cas...@fiserv.com wrote:
In addition, the Windows Installer engine starts producing log messages
before it loads the MSI package to determine what log file to use.
In short, one can set a log file:
* On the command line
* As an argument to MsiProductInstall()
* In the registry (global and applies to all MSI packages, cannot be changed
on a per package basis)
The MsiLogFileLocation property is automatically set by the Windows
Installer engine to allow a MSI UI to display the log file location on a
dialog. Changing the value of MsiLogFileLocation within the MSI package
itself does not change where the Windows Installer engine is logging to (as
evidenced by the tests performed by various people).
To automatically set a log file you'll need to use a bootstrapper as was
already suggested so that the bootstrapper can set it on the command line or
as an argument to MsiProductInstall().
Your system administrator could use the registry approach to control whether
all MSI packages generate a log file to a specific folder location with a
random: MSI*.LOG name.
This is documented in the MSDN documentation so if anybody wants to use this
approach I suggest they check MSDN at
http://msdn.microsoft.com/en-us/library/windows/desktop/aa372847.aspx
Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: Thursday, March 15, 2012 11:22 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Setting MsiLogFileLocation property
A good test anyone can try. Run a command something like this.
MSIEXEC.EXE /L*v C:\Foobar\test.log /I path to MSI
For that log folder that you point to make sure the C:\Foobar directly DOES
NOT EXIST.
Note how
Re: [WiX-users] Setting MsiLogFileLocation property
The following thread implied that the file log location can be set through MsiLogFileLocation property in WIX: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Msi-Logging-td707004.html#a707011 But it sounds like Rob is saying this is not possible. So, how can I reliably enable MSI logging programmatically in WIX code and ideally set the location of the log file? We need to support Windows XP SP2 and higher. Thanks, Alec On Thu, Mar 15, 2012 at 10:05 AM, Christopher Painter chr...@iswix.com wrote: I don't know if this is common knowledge but I don't set the MsiLogging property anymore. There' s a known bug in Windows 7 where Explorer / Shell can lose reference to the installer log file location and it causes the installer to crash out. It can manifest itself on uninstall which means you are stuck unless you run the uninstall from the command line passing in an explicit path. From: Rob Mensching r...@robmensching.com Sent: Thursday, March 15, 2012 11:02 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Setting MsiLogFileLocation property I don't think you can set the log file using MsiLogFileLocation. I think it *gets* set to the log file location. You can force your package to require MSI 4.0 by setting the Package/InstallerVersion attribute. On Wed, Mar 14, 2012 at 9:10 PM, Alec Swan alecs...@gmail.com wrote: Hello, I need to enable verbose logging and configure MSI log file location. I am currently doing this by adding the following properties inside of my .wxs file: Wix Product Property Id=LOGVERBOSE1/Property Property Id=MsiLogFileLocationx:/WIX/wix-msi.log/Property ... Is this the right place for these properties? If so, then I am assuming that the reason why they are not taking effect is that the MSI version our Wix project is using is lower than 4.0 and does not support MsiLogFileLocation property. Where do I update the MSI version in my WIX project? Thanks, Alec -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Setting MsiLogFileLocation property
Adam, This post indicates that it is possible to set MSI property from WIX: http://blogs.technet.com/b/alexshev/archive/2009/05/16/from-msi-to-wix-part-23-dll-custom-actions-logging-and-setting-properties.aspx If this is true, shouldn't I be able to use this approach to set some kind of MSI property to force logging and/or configure location of the log file? Enabling logging seems to be a pretty common question on the WIX forum, can we have WIX team to provide a recommendation on how to do this? Thanks, Alec On Thu, Mar 15, 2012 at 10:54 AM, Adam Kadzban mightyshorta...@gmail.com wrote: Alec, As far as I know, you can't set the log file location inside WIX because you need to tell msiexec where to write the log file to before actually starting the MSI. You need some sort of bootstrapper that calls msiexec with the logging options. I've used IExpress in the past, but I think I'll be switching to dotNetInstaller soon. -Adam On Thu, Mar 15, 2012 at 11:43 AM, John Cooper jocoo...@jackhenry.comwrote: I've seen the same bugs CP has seen. I've got it set in my installers, but only because CD demands it. Setting it causes a fair number of install failures, particular in install/repair/uninstall cycles. -- 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: Alec Swan [mailto:alecs...@gmail.com] Sent: Thursday, March 15, 2012 11:30 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Setting MsiLogFileLocation property The following thread implied that the file log location can be set through MsiLogFileLocation property in WIX: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Msi-Logging-td707004.html#a707011 But it sounds like Rob is saying this is not possible. So, how can I reliably enable MSI logging programmatically in WIX code and ideally set the location of the log file? We need to support Windows XP SP2 and higher. Thanks, Alec On Thu, Mar 15, 2012 at 10:05 AM, Christopher Painter chr...@iswix.com wrote: I don't know if this is common knowledge but I don't set the MsiLogging property anymore. There' s a known bug in Windows 7 where Explorer / Shell can lose reference to the installer log file location and it causes the installer to crash out. It can manifest itself on uninstall which means you are stuck unless you run the uninstall from the command line passing in an explicit path. From: Rob Mensching r...@robmensching.com Sent: Thursday, March 15, 2012 11:02 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Setting MsiLogFileLocation property I don't think you can set the log file using MsiLogFileLocation. I think it *gets* set to the log file location. You can force your package to require MSI 4.0 by setting the Package/InstallerVersion attribute. On Wed, Mar 14, 2012 at 9:10 PM, Alec Swan alecs...@gmail.com wrote: Hello, I need to enable verbose logging and configure MSI log file location. I am currently doing this by adding the following properties inside of my .wxs file: Wix Product Property Id=LOGVERBOSE1/Property Property Id=MsiLogFileLocationx:/WIX/wix-msi.log/Property ... Is this the right place for these properties? If so, then I am assuming that the reason why they are not taking effect is that the MSI version our Wix project is using is lower than 4.0 and does not support MsiLogFileLocation property. Where do I update the MSI version in my WIX project? Thanks, Alec -- -- -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- -- -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing
Re: [WiX-users] Setting MsiLogFileLocation property
Phil, thank you for sharing your experience. I would like to keep this thread active until we get a definite answer from the WIX team. Whether it is You can't enable MSI logging in the current version of WIX but will be available in version x.x or This is how you do this ... - it will still be very helpful. Thanks, Alec On Thu, Mar 15, 2012 at 11:32 AM, Wilson, Phil phil.wil...@invensys.com wrote: You can't set MsiLogFileLocation, as the MSDN docs pretty much say. You can try to set it but it's ineffective. If you set it in the property table it just gets overwritten. If you set it with a type 51 it just gets ignored. Phil W -Original Message- From: Alec Swan [mailto:alecs...@gmail.com] Sent: Thursday, March 15, 2012 10:09 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Setting MsiLogFileLocation property Adam, This post indicates that it is possible to set MSI property from WIX: http://blogs.technet.com/b/alexshev/archive/2009/05/16/from-msi-to-wix-part-23-dll-custom-actions-logging-and-setting-properties.aspx If this is true, shouldn't I be able to use this approach to set some kind of MSI property to force logging and/or configure location of the log file? Enabling logging seems to be a pretty common question on the WIX forum, can we have WIX team to provide a recommendation on how to do this? Thanks, Alec On Thu, Mar 15, 2012 at 10:54 AM, Adam Kadzban mightyshorta...@gmail.com wrote: Alec, As far as I know, you can't set the log file location inside WIX because you need to tell msiexec where to write the log file to before actually starting the MSI. You need some sort of bootstrapper that calls msiexec with the logging options. I've used IExpress in the past, but I think I'll be switching to dotNetInstaller soon. -Adam On Thu, Mar 15, 2012 at 11:43 AM, John Cooper jocoo...@jackhenry.comwrote: I've seen the same bugs CP has seen. I've got it set in my installers, but only because CD demands it. Setting it causes a fair number of install failures, particular in install/repair/uninstall cycles. -- 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: Alec Swan [mailto:alecs...@gmail.com] Sent: Thursday, March 15, 2012 11:30 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Setting MsiLogFileLocation property The following thread implied that the file log location can be set through MsiLogFileLocation property in WIX: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Msi-Logging-td707004.html#a707011 But it sounds like Rob is saying this is not possible. So, how can I reliably enable MSI logging programmatically in WIX code and ideally set the location of the log file? We need to support Windows XP SP2 and higher. Thanks, Alec On Thu, Mar 15, 2012 at 10:05 AM, Christopher Painter chr...@iswix.com wrote: I don't know if this is common knowledge but I don't set the MsiLogging property anymore. There' s a known bug in Windows 7 where Explorer / Shell can lose reference to the installer log file location and it causes the installer to crash out. It can manifest itself on uninstall which means you are stuck unless you run the uninstall from the command line passing in an explicit path. From: Rob Mensching r...@robmensching.com Sent: Thursday, March 15, 2012 11:02 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Setting MsiLogFileLocation property I don't think you can set the log file using MsiLogFileLocation. I think it *gets* set to the log file location. You can force your package to require MSI 4.0 by setting the Package/InstallerVersion attribute. On Wed, Mar 14, 2012 at 9:10 PM, Alec Swan alecs...@gmail.com wrote: Hello, I need to enable verbose logging and configure MSI log file location. I am currently doing this by adding the following properties inside of my .wxs file: Wix Product Property Id=LOGVERBOSE1/Property Property Id=MsiLogFileLocationx:/WIX/wix-msi.log/Property ... Is this the right place for these properties? If so, then I am assuming that the reason why they are not taking effect is that the MSI version our Wix project is using is lower than 4.0 and does not support MsiLogFileLocation property. Where do I update the MSI version in my WIX project? Thanks, Alec -- -- -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
Re: [WiX-users] Setting MsiLogFileLocation property
Wow, this is a pretty active mailing list. I think we have the definite answer now. As you can already tell I am a newbie to WIX, so please take it easy on me with my next question. What logging mechanism do you normally use to log messages from your custom actions? Thanks, Alec On Thu, Mar 15, 2012 at 12:58 PM, Castro, Edwin G. (Hillsboro) edwin.cas...@fiserv.com wrote: In addition, the Windows Installer engine starts producing log messages before it loads the MSI package to determine what log file to use. In short, one can set a log file: * On the command line * As an argument to MsiProductInstall() * In the registry (global and applies to all MSI packages, cannot be changed on a per package basis) The MsiLogFileLocation property is automatically set by the Windows Installer engine to allow a MSI UI to display the log file location on a dialog. Changing the value of MsiLogFileLocation within the MSI package itself does not change where the Windows Installer engine is logging to (as evidenced by the tests performed by various people). To automatically set a log file you'll need to use a bootstrapper as was already suggested so that the bootstrapper can set it on the command line or as an argument to MsiProductInstall(). Your system administrator could use the registry approach to control whether all MSI packages generate a log file to a specific folder location with a random: MSI*.LOG name. This is documented in the MSDN documentation so if anybody wants to use this approach I suggest they check MSDN at http://msdn.microsoft.com/en-us/library/windows/desktop/aa372847.aspx Edwin G. Castro Software Developer - Staff Digital Channels Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: Thursday, March 15, 2012 11:22 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Setting MsiLogFileLocation property A good test anyone can try. Run a command something like this. MSIEXEC.EXE /L*v C:\Foobar\test.log /I path to MSI For that log folder that you point to make sure the C:\Foobar directly DOES NOT EXIST. Note how MSIEXEC.EXE will simply error out rather than creating the Foobar folder in which to create the log file. I feel this shows an example of what Edwin and others are talking about. Log file must be established before MSIEXEC calls into the MSI. -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Thursday, March 15, 2012 11:10 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Setting MsiLogFileLocation property WiX is not in control of the MsiLogFileLocation property. This is functionality provided by Windows Installer. As mentioned earlier, the log file location must be set before the MSI package is loaded by the Windows Installer engine. This is how Windows Installer works and the WiX team has no control over it. Please refer to http://msdn.microsoft.com/en- us/library/windows/desktop/aa372847.aspx for information on Windows Installer Logging. In particular check the Normal Logging section at http://msdn.microsoft.com/en-us/library/windows/desktop/aa370536.aspx for an explanation of your options. Edwin G. Castro Software Developer - Staff Digital Channels Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Alec Swan [mailto:alecs...@gmail.com] Sent: Thursday, March 15, 2012 10:44 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Setting MsiLogFileLocation property Phil, thank you for sharing your experience. I would like to keep this thread active until we get a definite answer from the WIX team. Whether it is You can't enable MSI logging in the current version of WIX but will be available in version x.x or This is how you do this ... - it will still be very helpful. Thanks, Alec On Thu, Mar 15, 2012 at 11:32 AM, Wilson, Phil phil.wil...@invensys.com wrote: You can't set MsiLogFileLocation, as the MSDN docs pretty much say. You can try to set it but it's ineffective. If you set it in the property table it just gets overwritten. If you set it with a type 51 it just gets ignored. Phil W -Original Message- From: Alec Swan [mailto:alecs...@gmail.com] Sent: Thursday, March 15, 2012 10:09 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Setting MsiLogFileLocation property Adam, This post indicates that it is possible to set MSI property from WIX: http://blogs.technet.com/b/alexshev/archive/2009/05/16/from-msi-to- wix -part-23-dll-custom-actions-logging
[WiX-users] Setting MsiLogFileLocation property
Hello, I need to enable verbose logging and configure MSI log file location. I am currently doing this by adding the following properties inside of my .wxs file: Wix Product Property Id=LOGVERBOSE1/Property Property Id=MsiLogFileLocationx:/WIX/wix-msi.log/Property ... Is this the right place for these properties? If so, then I am assuming that the reason why they are not taking effect is that the MSI version our Wix project is using is lower than 4.0 and does not support MsiLogFileLocation property. Where do I update the MSI version in my WIX project? Thanks, Alec -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
