Re: [WiX-users] Patch failure on XP that doesn't happen on Vista
I am using PatchWiz. Also, I am afraid I don't understand if I should use IgnoreRange, if I could do it with PatchWiz. On XP the patching system thinks that file has been already patched which is simply wrong, even if the difference is probably only in version resource part of the file. It also aborts the patching process and rolls back all the changes. I can't patch the entire system anymore because of this error. I would rather see the same behavior as in Vista where the same file gets patched and I see it got a new version when looking at its properties in Explorer. Thus I am thinking either play with installer versions, of which XP one appears to be buggy, or take your suggestion to include the entire file in the patch, rather than using differences. -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, September 02, 2009 1:13 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista TargetFile\IgnoreRange element(s) are intended for exactly your scenario (you tell the system one or more sections of the binary that don't matter for it to be able to assert that the file is the same before applying the patch it). If you are using Pyro instead of PatchWiz, the IgnoreRange element goes under the File element in building your Updated image (it seems to be missing from the schema/help doc). -Original Message- From: Tony Juricic [mailto:tjuri...@tradestation.com] Sent: Tuesday, September 01, 2009 6:08 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista Hi Blair, Actually, the files are not bit-for-bit the same. The error message is probably too generic and misleading in this case. In the case of this particular file there are no changes in code and the only difference is in version resource which has 4-th version number different from the RTM version. IMO, that explains why PatchSize=6113,TargetSize=100198. This is nothing unusual considering the build system that I am using, which increments 4-th version number with each new build. Quite a few other files have the same differences - just version resource - and they don't exhibit this problem. I build MSP on Server 2003 system with MSI version 3.01.4000.3959 and I create only Release build patches. It seems that patch application MSI version is more important than the build system MSI version since patch applies without a glitch on Vista with version V 4.5.6002.18005 MSI, while it fails on XP with MSI components version 3.01. I guess I would have to enforce both build and application MSI versions to be the same (meaning I'll have to install 4.5 MSI on XP machines before staring install and patching process), but at this time it is just a guess. Thanks, Tony -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, September 01, 2009 6:20 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista I assumed you verified that the files are bit-for-bit the same before attempting to apply the patch. Do you build your MSP on a Vista/Server 2008 system? We saw this one time and it happened only with Release (not Debug) for just one file, but didn't happen when building on XP/32-bit (I never investigated building on either 64-bit XP or Server 2003). Our products were not allowed on Server OSs but we did our official builds on them. It seems that the PatchAPI binaries (described here: http://msdn.microsoft.com/en-us/library/bb417345.aspx) are somehow different and the Patch Apply routines are somehow sometimes different between platforms. For a workaround we had to mark that one file as whole file instead of delta. It didn't happen every build, but it did happen for about two months around one of our major releases. -Original Message- From: Tony Juricic [mailto:tjuri...@tradestation.com] Sent: Tuesday, September 01, 2009 2:56 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patch failure on XP that doesn't happen on Vista Applying the patch on one XP system produces the following error log for one file (edited here to shorten the path to MYFILE.EXE): MSI (s) (74:4C) [17:23:03:041]: Executing op: CacheBaselineFile(Baseline=0,FileKey=MYFILE.EXE,FilePath=C:\Program Files\..\ MYFILE.EXE,,Existing=0) MSI (s) (74:4C) [17:23:03:103]: Executing op: PatchApply(PatchName= MYFILE.EXE,TargetName=C:\Program Files\..\ MYFILE.EXE,PatchSize=6113,TargetSize=1001984,PerTick=0,,FileAttributes=512,P atchAttributes=0,CheckCRC=0) MSI (s) (74:4C) [17:23:03:135]: Re-applying security from existing file. MSI (s) (74:4C) [17:23:03:197]: Note: 1: 2318 2: C:\Config.Msi\PF4D1.tmp MSI (s) (74:4C) [17:23:03:244]: Note: 1: 2302 2: 0 MSI (s) (74:4C) [17:23:03:338]: Note: 1: 1328 2: C:\Program Files\... MYFILE.EXE 3: -1072807676 MSI (s) (74:4C)
Re: [WiX-users] How to check the prerequisite software install?
Hi Sebastian, Thank you for your reply. I tried the method as you suggested. The following is my code: Property Id=SYBASE_MAJORVERSION RegistrySearch Id=RegSearch_Sybase_MajorVersion Key=SOFTWARE\Sybase\SQL Anywhere\10.0 Root=HKLM Type=raw / /Property Condition Message=MyApp requires Sybase 10.0. Please make sure it is installed.SYBASE_MAJORVERSION/Condition However, when I install my msi, it always pops uo the warning message, saying MyApp requires Sybase 10.0. Please make sure it is installed. I checked the registration. And the key SOFTWARE\Sybase\SQL Anywhere\10.0 does exist. I compared it with your example Adobe. Under Software\Adobe\Acrobat Reader\9.0\InstallPath, there is key value: (standard) REG_SZ C:\Program\Adobe\Reader But under SOFTWARE\Sybase\SQL Anywhere\10.0, the key value is: (standard) REG_SZ (No value) Folder REG_SZ SQL Anywhere 10 JRE Version REG_SZ 5.0.100.3 LanguageREG_SZ DE LocationREG_SZ C:\Program Files\SQL Anywhere 10 Online Resources REG_SZC:\Program Files\SQL Anywhere 10\support\ianywhere.html Samples Location REG_SZD:\Documents and Settings\All Users\Documents\SQL Anywhere 10\Samples Shared Location REG_SZC:\Program Files\SQL Anywhere 10 Is there something wrong in my Property? How can I change it? Best regards, Chunyan -Ursprüngliche Nachricht- Von: Sebastian Brand (Instyler Software) [mailto:wix+us...@instyler.com] Gesendet: Dienstag, 1. September 2009 16:07 An: 'General discussion for Windows Installer XML toolset.' Betreff: Re: [WiX-users] How to check the prerequisite software install? Hi, Add a Condition right under Product. The message in the @Message attribute will be shown whenever the condition is false, and setup is aborted. The condition should contain a Property that gets initialized with RegistrySearch or FileSearch to find a registry value or file from the other software to identify if it is installed. Example: Product Property Id=ADOBEREADER9INSTALLED RegistrySearch Id=ADOBEREADER9INSTALLED_REGSEARCH Key=Software\Adobe\Acrobat Reader\9.0\InstallPath Root=HKLM Type=raw / /Property Condition Message=[ProductName] requires Adobe Reader 9.0 Please make sure you it installed.ADOBEREADER9INSTALLED/Condition ... /Product Best regards, Sebastian Brand Instyler Setup - Creating WiX-based MSI installations, elegantly. http://www.instyler.com -Original Message- From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com] Sent: Tuesday, September 01, 2009 14:46 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] How to check the prerequisite software install? Hi Wix-users, My software needs another software (Sybase) as the prerequisite. Therefore I need to check whether Sybase has been installed in the machine and show the warning message if it is not installed. How can I define the condition in the installer? Best regards, Chunyan -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to check the prerequisite software install?
One option would be to try: Property Id=SYBASE_10INSTALLATION RegistrySearch Id=RegSearch_Sybase_MajorVersion Name=Location Key=SOFTWARE\Sybase\SQL Anywhere\10.0 Root=HKLM Type=raw / /Property Condition Message=MyApp requires Sybase 10.0. Please make sure it is installed.SYBASE_10INSTALLATION/Condition But, I have another question. Is this on a 64-bit OS with a 32-bit MSI? -Original Message- From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com] Sent: Wednesday, September 02, 2009 6:45 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to check the prerequisite software install? Hi Sebastian, Thank you for your reply. I tried the method as you suggested. The following is my code: Property Id=SYBASE_MAJORVERSION RegistrySearch Id=RegSearch_Sybase_MajorVersion Key=SOFTWARE\Sybase\SQL Anywhere\10.0 Root=HKLM Type=raw / /Property Condition Message=MyApp requires Sybase 10.0. Please make sure it is installed.SYBASE_MAJORVERSION/Condition However, when I install my msi, it always pops uo the warning message, saying MyApp requires Sybase 10.0. Please make sure it is installed. I checked the registration. And the key SOFTWARE\Sybase\SQL Anywhere\10.0 does exist. I compared it with your example Adobe. Under Software\Adobe\Acrobat Reader\9.0\InstallPath, there is key value: (standard) REG_SZ C:\Program\Adobe\Reader But under SOFTWARE\Sybase\SQL Anywhere\10.0, the key value is: (standard) REG_SZ (No value) Folder REG_SZ SQL Anywhere 10 JRE Version REG_SZ 5.0.100.3 LanguageREG_SZ DE LocationREG_SZ C:\Program Files\SQL Anywhere 10 Online Resources REG_SZC:\Program Files\SQL Anywhere 10\support\ianywhere.html Samples Location REG_SZD:\Documents and Settings\All Users\Documents\SQL Anywhere 10\Samples Shared Location REG_SZC:\Program Files\SQL Anywhere 10 Is there something wrong in my Property? How can I change it? Best regards, Chunyan -Ursprüngliche Nachricht- Von: Sebastian Brand (Instyler Software) [mailto:wix+us...@instyler.com] Gesendet: Dienstag, 1. September 2009 16:07 An: 'General discussion for Windows Installer XML toolset.' Betreff: Re: [WiX-users] How to check the prerequisite software install? Hi, Add a Condition right under Product. The message in the @Message attribute will be shown whenever the condition is false, and setup is aborted. The condition should contain a Property that gets initialized with RegistrySearch or FileSearch to find a registry value or file from the other software to identify if it is installed. Example: Product Property Id=ADOBEREADER9INSTALLED RegistrySearch Id=ADOBEREADER9INSTALLED_REGSEARCH Key=Software\Adobe\Acrobat Reader\9.0\InstallPath Root=HKLM Type=raw / /Property Condition Message=[ProductName] requires Adobe Reader 9.0 Please make sure you it installed.ADOBEREADER9INSTALLED/Condition ... /Product Best regards, Sebastian Brand Instyler Setup - Creating WiX-based MSI installations, elegantly. http://www.instyler.com -Original Message- From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com] Sent: Tuesday, September 01, 2009 14:46 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] How to check the prerequisite software install? Hi Wix-users, My software needs another software (Sybase) as the prerequisite. Therefore I need to check whether Sybase has been installed in the machine and show the warning message if it is not installed. How can I define the condition in the installer? Best regards, Chunyan -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment -
[WiX-users] candle -arch
Rob's latest blog refers to the -arch option for candle. I can't find any documentation for what that does example. It apparently implicitly sets the Package/@Platform. What else does it do? I tried following it in the code, but got lost pretty quick. My project uses $(var.Platform) in Package/@Description, Package/@Comments, Package/@Platform, and in the precompiler to choose launch conditions. I just set it using candle -dPlatform=... Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to check the prerequisite software install?
Thanks Blair! I tried your method that adding Name attribute to Property. And it works! My OS is Windows XP Professional. I don't know if it is 64-bit or not. What is 32-bit MSI? Regards, Chunyan -Ursprüngliche Nachricht- Von: Blair [mailto:os...@live.com] Gesendet: Mittwoch, 2. September 2009 16:51 An: 'General discussion for Windows Installer XML toolset.' Betreff: Re: [WiX-users] How to check the prerequisite software install? One option would be to try: Property Id=SYBASE_10INSTALLATION RegistrySearch Id=RegSearch_Sybase_MajorVersion Name=Location Key=SOFTWARE\Sybase\SQL Anywhere\10.0 Root=HKLM Type=raw / /Property Condition Message=MyApp requires Sybase 10.0. Please make sure it is installed.SYBASE_10INSTALLATION/Condition But, I have another question. Is this on a 64-bit OS with a 32-bit MSI? -Original Message- From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com] Sent: Wednesday, September 02, 2009 6:45 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to check the prerequisite software install? Hi Sebastian, Thank you for your reply. I tried the method as you suggested. The following is my code: Property Id=SYBASE_MAJORVERSION RegistrySearch Id=RegSearch_Sybase_MajorVersion Key=SOFTWARE\Sybase\SQL Anywhere\10.0 Root=HKLM Type=raw / /Property Condition Message=MyApp requires Sybase 10.0. Please make sure it is installed.SYBASE_MAJORVERSION/Condition However, when I install my msi, it always pops uo the warning message, saying MyApp requires Sybase 10.0. Please make sure it is installed. I checked the registration. And the key SOFTWARE\Sybase\SQL Anywhere\10.0 does exist. I compared it with your example Adobe. Under Software\Adobe\Acrobat Reader\9.0\InstallPath, there is key value: (standard) REG_SZ C:\Program\Adobe\Reader But under SOFTWARE\Sybase\SQL Anywhere\10.0, the key value is: (standard) REG_SZ (No value) Folder REG_SZ SQL Anywhere 10 JRE Version REG_SZ 5.0.100.3 LanguageREG_SZ DE LocationREG_SZ C:\Program Files\SQL Anywhere 10 Online Resources REG_SZC:\Program Files\SQL Anywhere 10\support\ianywhere.html Samples Location REG_SZD:\Documents and Settings\All Users\Documents\SQL Anywhere 10\Samples Shared Location REG_SZC:\Program Files\SQL Anywhere 10 Is there something wrong in my Property? How can I change it? Best regards, Chunyan -Ursprüngliche Nachricht- Von: Sebastian Brand (Instyler Software) [mailto:wix+us...@instyler.com] Gesendet: Dienstag, 1. September 2009 16:07 An: 'General discussion for Windows Installer XML toolset.' Betreff: Re: [WiX-users] How to check the prerequisite software install? Hi, Add a Condition right under Product. The message in the @Message attribute will be shown whenever the condition is false, and setup is aborted. The condition should contain a Property that gets initialized with RegistrySearch or FileSearch to find a registry value or file from the other software to identify if it is installed. Example: Product Property Id=ADOBEREADER9INSTALLED RegistrySearch Id=ADOBEREADER9INSTALLED_REGSEARCH Key=Software\Adobe\Acrobat Reader\9.0\InstallPath Root=HKLM Type=raw / /Property Condition Message=[ProductName] requires Adobe Reader 9.0 Please make sure you it installed.ADOBEREADER9INSTALLED/Condition ... /Product Best regards, Sebastian Brand Instyler Setup - Creating WiX-based MSI installations, elegantly. http://www.instyler.com -Original Message- From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com] Sent: Tuesday, September 01, 2009 14:46 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] How to check the prerequisite software install? Hi Wix-users, My software needs another software (Sybase) as the prerequisite. Therefore I need to check whether Sybase has been installed in the machine and show the warning message if it is not installed. How can I define the condition in the installer? Best regards, Chunyan -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application
Re: [WiX-users] Failed while processing WebDirs
I am able to reproduce your failure - I haven't investigated in detail yet, but
it could be a bug. Go ahead and file a bug on SF against WiX 3.5, and attach
your repro authoring to the bug.
Thanks,
Mike Carlson
-Original Message-
From: Yan Sklyarenko [mailto:y...@sitecore.net]
Sent: Wednesday, September 02, 2009 4:44 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Failed while processing WebDirs
Hi Mike,
I've managed to localize the problem. This looks like a bug in WiX IIS
extension to me. Here's the description.
I have several components, each contains a iis:WebSite element. This way
I specify different settings for IIS 5, 6 and 7 web sites. Each website
has the iis:WebDir element inside to point to the folder under the site
root. So, the problem is there when there are two and more web sites. It
seems that a method processing web dirs doesn't assume the install state
of the parent component.
Below is a sample project source. It is 100% reproduced for both IIS 5
and IIS 6.
Could you please confirm it is a bug?
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
xmlns:iis=http://schemas.microsoft.com/wix/IIsExtension;
Product Id=bf1fd3b5-af21-462d-98c4-87685f7d425c
Name=TestProject
Language=1033
Version=1.0.0.0
Manufacturer=TestProject
UpgradeCode=3f0ca2c9-e332-4375-986f-4278261ac948
Package InstallerVersion=200 Compressed=yes /
Media Id=1 Cabinet=media1.cab EmbedCab=yes /
PropertyRef Id=IISMAJORVERSION/
PropertyRef Id=IISMINORVERSION/
Directory Id=TARGETDIR Name=SourceDir
Directory Id=INSTALLLOCATION Name=TestProject
Directory Id=Upload Name=upload
Component Id=UploadComponent
Guid={8E50F0DE-622E-4268-B2F3-3ED06C07585D}
CreateFolder /
/Component
/Directory
Component Id=ProductComponent
Guid=937B78FF-2FA2-4CBF-9648-602F7BA434E8
File Id=SampleFile Name=default.aspx
Source=$(var.SourcePath)\default.aspx /
/Component
Component Id=IIS5SiteComponent
Guid={C132F7A0-B429-48A5-83BC-4CBC878AEC06} Permanent=yes
ConditionIISMAJORVERSION = #5/Condition
CreateFolder /
iis:WebSite Id=IIS5Site SiteId=1 AutoStart=yes
ConfigureIfExists=yes Description=Default Web Site
Directory=INSTALLLOCATION DirProperties=SiteDirProperties
WebApplication=App5
iis:WebAddress Id=IISSite5Address Port=80/
iis:WebDir Id=Upload5WebDir Path=upload
iis:WebDirProperties Id=Upload5DirProperties
AnonymousAccess=yes IIsControlledPassword=yes/
/iis:WebDir
/iis:WebSite
/Component
Component Id=IIS6SiteComponent
Guid={32DDD19A-4D4F-4544-81AE-FD174FCC91F6}
ConditionIISMAJORVERSION = #6/Condition
CreateFolder /
iis:WebSite Id=IIS6Site SiteId=6 AutoStart=yes
Description=TestProjectSite6 Directory=INSTALLLOCATION
DirProperties=SiteDirProperties WebApplication=App6
iis:WebAddress Id=IISSite6Address Port=80/
iis:WebDir Id=Upload6WebDir Path=upload
iis:WebDirProperties Id=Upload6DirProperties
AnonymousAccess=yes IIsControlledPassword=yes/
/iis:WebDir
/iis:WebSite
/Component
/Directory
/Directory
iis:WebApplication Id=App5 Name=WebApplication5
Isolation=medium /
iis:WebApplication Id=App6 Name=WebApplication6 /
iis:WebDirProperties Id=SiteDirProperties AnonymousAccess=yes
WindowsAuthentication=no IIsControlledPassword=yes
DefaultDocuments=default.aspx/
Feature Id=ProductFeature Title=Feature1 Level=1
ComponentRef Id=ProductComponent /
ComponentRef Id=IIS5SiteComponent/
ComponentRef Id=IIS6SiteComponent/
ComponentRef Id=UploadComponent/
/Feature
/Product
/Wix
-- Yan
-Original Message-
From: Yan Sklyarenko [mailto:y...@sitecore.net]
Sent: Tuesday, September 01, 2009 7:07 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Failed while processing WebDirs
Sure, here you go:
iis:WebError ErrorCode=404 SubCode=0
URL=/sitecore/service/notfound.aspx/
iis:MimeMap Id=XAP6_new Extension=.xap
Type=application/x-silverlight-app/
iis:MimeMap Id=XAML6_new Extension=.xaml
Type=application/xaml+xml/
-- Yan
-Original Message-
From: Mike Carlson (DEV DIV) [mailto:mica...@microsoft.com]
Sent: Tuesday, September 01, 2009 7:04 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Failed while processing WebDirs
Thanks - could you also paste the contents of IIS6newsite.wxi?
-Original Message-
From: Yan Sklyarenko [mailto:y...@sitecore.net]
Sent: Tuesday, September 01,
Re: [WiX-users] candle -arch
I believe it also controls the default bit-ness for the Win64 attribute on certain things like RegistrySearches, Components, and binary Custom Actions (if you specify a 64-bit architecture, these will default to 64-bit). To see where it's used in the code, I'd open src\wix\compiler.cs and search for currentplatform. Once you get past the initial few results (which are just common infrastructure), you'll see where it actually takes effect. Thanks, Mike Carlson -Original Message- From: Quinton Tormanen [mailto:quint...@deltacompsys.com] Sent: Wednesday, September 02, 2009 8:21 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] candle -arch Rob's latest blog refers to the -arch option for candle. I can't find any documentation for what that does example. It apparently implicitly sets the Package/@Platform. What else does it do? I tried following it in the code, but got lost pretty quick. My project uses $(var.Platform) in Package/@Description, Package/@Comments, Package/@Platform, and in the precompiler to choose launch conditions. I just set it using candle -dPlatform=... Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Failed while processing WebDirs
Done: #2849248.
Is it possible to be fixed for WiX 3.0 as a hotfix for the released
version?
I'm not sure it is a good idea to switch to unstable 3.5 for
production...
Or, as a alternative, can you please attach a patch that fixes this to
the artifact? I can then have my custom build based on 3.0 plus this
fix?
Thank you.
-- Yan
-Original Message-
From: Mike Carlson (DEV DIV) [mailto:mica...@microsoft.com]
Sent: Wednesday, September 02, 2009 6:52 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Failed while processing WebDirs
I am able to reproduce your failure - I haven't investigated in detail
yet, but it could be a bug. Go ahead and file a bug on SF against WiX
3.5, and attach your repro authoring to the bug.
Thanks,
Mike Carlson
-Original Message-
From: Yan Sklyarenko [mailto:y...@sitecore.net]
Sent: Wednesday, September 02, 2009 4:44 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Failed while processing WebDirs
Hi Mike,
I've managed to localize the problem. This looks like a bug in WiX IIS
extension to me. Here's the description.
I have several components, each contains a iis:WebSite element. This way
I specify different settings for IIS 5, 6 and 7 web sites. Each website
has the iis:WebDir element inside to point to the folder under the site
root. So, the problem is there when there are two and more web sites. It
seems that a method processing web dirs doesn't assume the install state
of the parent component.
Below is a sample project source. It is 100% reproduced for both IIS 5
and IIS 6.
Could you please confirm it is a bug?
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
xmlns:iis=http://schemas.microsoft.com/wix/IIsExtension;
Product Id=bf1fd3b5-af21-462d-98c4-87685f7d425c
Name=TestProject
Language=1033
Version=1.0.0.0
Manufacturer=TestProject
UpgradeCode=3f0ca2c9-e332-4375-986f-4278261ac948
Package InstallerVersion=200 Compressed=yes /
Media Id=1 Cabinet=media1.cab EmbedCab=yes /
PropertyRef Id=IISMAJORVERSION/
PropertyRef Id=IISMINORVERSION/
Directory Id=TARGETDIR Name=SourceDir
Directory Id=INSTALLLOCATION Name=TestProject
Directory Id=Upload Name=upload
Component Id=UploadComponent
Guid={8E50F0DE-622E-4268-B2F3-3ED06C07585D}
CreateFolder /
/Component
/Directory
Component Id=ProductComponent
Guid=937B78FF-2FA2-4CBF-9648-602F7BA434E8
File Id=SampleFile Name=default.aspx
Source=$(var.SourcePath)\default.aspx /
/Component
Component Id=IIS5SiteComponent
Guid={C132F7A0-B429-48A5-83BC-4CBC878AEC06} Permanent=yes
ConditionIISMAJORVERSION = #5/Condition
CreateFolder /
iis:WebSite Id=IIS5Site SiteId=1 AutoStart=yes
ConfigureIfExists=yes Description=Default Web Site
Directory=INSTALLLOCATION DirProperties=SiteDirProperties
WebApplication=App5
iis:WebAddress Id=IISSite5Address Port=80/
iis:WebDir Id=Upload5WebDir Path=upload
iis:WebDirProperties Id=Upload5DirProperties
AnonymousAccess=yes IIsControlledPassword=yes/
/iis:WebDir
/iis:WebSite
/Component
Component Id=IIS6SiteComponent
Guid={32DDD19A-4D4F-4544-81AE-FD174FCC91F6}
ConditionIISMAJORVERSION = #6/Condition
CreateFolder /
iis:WebSite Id=IIS6Site SiteId=6 AutoStart=yes
Description=TestProjectSite6 Directory=INSTALLLOCATION
DirProperties=SiteDirProperties WebApplication=App6
iis:WebAddress Id=IISSite6Address Port=80/
iis:WebDir Id=Upload6WebDir Path=upload
iis:WebDirProperties Id=Upload6DirProperties
AnonymousAccess=yes IIsControlledPassword=yes/
/iis:WebDir
/iis:WebSite
/Component
/Directory
/Directory
iis:WebApplication Id=App5 Name=WebApplication5
Isolation=medium /
iis:WebApplication Id=App6 Name=WebApplication6 /
iis:WebDirProperties Id=SiteDirProperties AnonymousAccess=yes
WindowsAuthentication=no IIsControlledPassword=yes
DefaultDocuments=default.aspx/
Feature Id=ProductFeature Title=Feature1 Level=1
ComponentRef Id=ProductComponent /
ComponentRef Id=IIS5SiteComponent/
ComponentRef Id=IIS6SiteComponent/
ComponentRef Id=UploadComponent/
/Feature
/Product
/Wix
-- Yan
-Original Message-
From: Yan Sklyarenko [mailto:y...@sitecore.net]
Sent: Tuesday, September 01, 2009 7:07 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Failed while processing WebDirs
Sure, here you go:
iis:WebError ErrorCode=404 SubCode=0
[WiX-users] Starting another install at the end of a WIX installer
We use wix to create installers for our product in our office. Now, I have to call or trigger another third party installer (an .exe file) after my wix installer has finished installing. Are there any hooks in wix that will let me do something like that ? Any advise that will point me in the right direction will be very helpful. Thanks RK Meiappan. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Setting account info in merge module from MSI dialog
I'm cutting my teeth on WiX 3 by converting an InstallShield MSI to a proper MSI, and I'm running into a problem with the services merge modules. I have three services, each with their own merge module, that need to be registered with a domain account. I have not been able to figure out how to get the account and password properties passed down from my dialog to the merge module. I've found plenty of info on accessing properties in merge modules, and I have no problem getting the services to install with hard-coded values, but this one little gap is still eluding me. If I use ConfigurationData in the MergeRef it doesn't appear to set the value (I'm guessing this is set at compile time?) and I'm running out of ideas. Any suggestions are much appreciated! # Nathan -- View this message in context: http://n2.nabble.com/Setting-account-info-in-merge-module-from-MSI-dialog-tp3568432p3568432.html Sent from the wix-users mailing list archive at Nabble.com. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Setting account info in merge module from MSI dialog
How that is done really depends on the merge module. Who wrote those? -Original Message- From: NateBank [mailto:etherw...@gmail.com] Sent: Wednesday, September 02, 2009 11:02 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Setting account info in merge module from MSI dialog I'm cutting my teeth on WiX 3 by converting an InstallShield MSI to a proper MSI, and I'm running into a problem with the services merge modules. I have three services, each with their own merge module, that need to be registered with a domain account. I have not been able to figure out how to get the account and password properties passed down from my dialog to the merge module. I've found plenty of info on accessing properties in merge modules, and I have no problem getting the services to install with hard-coded values, but this one little gap is still eluding me. If I use ConfigurationData in the MergeRef it doesn't appear to set the value (I'm guessing this is set at compile time?) and I'm running out of ideas. Any suggestions are much appreciated! # Nathan -- View this message in context: http://n2.nabble.com/Setting-account-info-in-merge-module-from-MSI-dialog-tp 3568432p3568432.html Sent from the wix-users mailing list archive at Nabble.com. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Starting another install at the end of a WIX installer
These installers are still for your office? Do you always distribute them in such a fashion as to have UI from the MSIs shown to the user? If so, you could try adapting the launch after install pattern mentioned in the tutorial and this list. -Original Message- From: Radhakrishnan Meiappan [mailto:rmeiap...@datacert.com] Sent: Wednesday, September 02, 2009 9:44 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Starting another install at the end of a WIX installer We use wix to create installers for our product in our office. Now, I have to call or trigger another third party installer (an .exe file) after my wix installer has finished installing. Are there any hooks in wix that will let me do something like that ? Any advise that will point me in the right direction will be very helpful. Thanks RK Meiappan. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Setting account info in merge module from MSI dialog
I'm re-authoring them from scratch. Currently the merge modules are just a small collection of file components, one of them being the service exe that needs to be registered. The service component looks like so: Component Id=DispatcherService.exe Guid=hey-look-a-guid SharedDllRefCount=no KeyPath=no NeverOverwrite=no Permanent=no Transitive=no Win64=no Location=local File Id=DispatcherService.exe Name=DispatcherService.exe Source=$(var.DispatcherServiceFolder)\DispatcherService.exe ReadOnly=no Compressed=yes KeyPath=yes Vital=yes Hidden=no System=no Checksum=no / ServiceInstall Id=DispatcherServiceInstall Name=DispatcherService.exe DisplayName=Dispatcher v.$(var.ProductVersion) Description=Dispatcher Service for version $(var.ProductVersion) ErrorControl=normal Start=auto Type=ownProcess Vital=yes Account=[ServiceLogonAccount] Password=[ServiceLogonPassword] / ServiceControl Id=DispatcherServiceControl Name=DispatcherService.exe Start=install Stop=uninstall Remove=uninstall / /Component Blair-2 wrote: How that is done really depends on the merge module. Who wrote those? -- View this message in context: http://n2.nabble.com/Setting-account-info-in-merge-module-from-MSI-dialog-tp3568432p3568743.html Sent from the wix-users mailing list archive at Nabble.com. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Starting another install at the end of a WIXinstaller
Thanks. I can't find the 'launch after install' pattern in the tutorial nor in the user-list archive. Can you send me the url to either one of those. RK Meiappan -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, September 02, 2009 1:14 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Starting another install at the end of a WIXinstaller These installers are still for your office? Do you always distribute them in such a fashion as to have UI from the MSIs shown to the user? If so, you could try adapting the launch after install pattern mentioned in the tutorial and this list. -Original Message- From: Radhakrishnan Meiappan [mailto:rmeiap...@datacert.com] Sent: Wednesday, September 02, 2009 9:44 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Starting another install at the end of a WIX installer We use wix to create installers for our product in our office. Now, I have to call or trigger another third party installer (an .exe file) after my wix installer has finished installing. Are there any hooks in wix that will let me do something like that ? Any advise that will point me in the right direction will be very helpful. Thanks RK Meiappan. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] hoping for confirmation
OK, so now I have MigrateFeatureStates actually doing something.
However, it is still attempting to migrate the features states from all
of the installed instances of my application. The property listed in my
Upgrade table to use for storing the product codes to upgrade is
OLDAPPFOUND. The action to set this to the single product code I am
interested in upgrading is SetOLDAPPFOUND, which is running directly
before MigrateFeatureStates. From the verbose log:
Action 12:55:16: SetOLDAPPFOUND.
Action start 12:55:16: SetOLDAPPFOUND.
MSI (c) (54:FC) [12:55:16:640]: PROPERTY CHANGE: Modifying OLDAPPFOUND
property. Its current value is
'{20ED61C2-44DA-4CD4-AD05-DBE0F7ACAE7C};{1479021E-2170-497D-B05A-A4BFE94
0A624};{009EC31E-E7DE-463B-94EB-9D24623563D8};{F3E31D03-45F2-4733-B5C0-0
A4ED7B0D023};{23A8B2E0-6BF3-4369-A55F-6230744351DE};{82D91CB2-0C1E-4AAB-
949B-221F7EF4C12F}'. Its new value:
'{009EC31E-E7DE-463B-94EB-9D24623563D8}'.
Action ended 12:55:16: SetOLDAPPFOUND. Return value 1.
MSI (c) (54:FC) [12:55:16:641]: Doing action: MigrateFeatureStates
Action 12:55:16: MigrateFeatureStates. Migrating feature states from
related applications
Action start 12:55:16: MigrateFeatureStates.
MSI (c) (54:FC) [12:55:16:641]: Migrating feature settings from
product(s)
'{20ED61C2-44DA-4CD4-AD05-DBE0F7ACAE7C};{1479021E-2170-497D-B05A-A4BFE94
0A624};{009EC31E-E7DE-463B-94EB-9D24623563D8};{F3E31D03-45F2-4733-B5C0-0
A4ED7B0D023};{23A8B2E0-6BF3-4369-A55F-6230744351DE};{82D91CB2-0C1E-4AAB-
949B-221F7EF4C12F}'
As you can see, although the OLDAPPFOUND property is set to the single
guid for the specific instance I care about, the MigrateFeatureStates
action is still using the list of guids detected during
FindRelatedProducts.
Any idea how I can change that list MigrateFeatureStates is working
with?
Thanks again!
Amy
-Original Message-
From: Amy Rosewater [mailto:arosewa...@spectrumhr.com]
Sent: Tuesday, September 01, 2009 1:04 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] hoping for confirmation
Ah thank you! I knew I must be missing something simple.
Amy
-Original Message-
From: Alexander Shevchuk (Volt) [mailto:a-ale...@microsoft.com]
Sent: Tuesday, September 01, 2009 11:29 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] hoping for confirmation
Hi Amy,
Did you set UpgradeVersion/@MigrateFeatures to yes on product you want
to upgrade?
Alex
-Original Message-
From: Amy Rosewater [mailto:arosewa...@spectrumhr.com]
Sent: Tuesday, September 01, 2009 9:28 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] hoping for confirmation
Hi All,
I am working on some minor issues in a major upgrade. :) I was hoping
someone could tell me a little about the MigrateFeatureStates action
when you have an installer that permits multiple embedded transforms of
the product code.
My install is in wix v3. I have a custom action which modifies the
property I use to keep track of the product codes of already installed
applications (in the Upgrade table). My property is OLDAPPFOUND. With
verbose logging, I can see that the OLDAPPFOUND property gets set to a
series of product codes, one for each installed instance of my
application. However, since I want to only upgrade one specific
instance, I later set the OLDAPPFOUND property to the product code for
the specific instance I want to upgrade. This definitely works as I
want.
However, currently, I have my custom action SetOLDAPPFOUND scheduled
after MigrateFeatureStates in the InstallExecuteSequence. The result
seems to be that despite what features were selected for install in the
product being upgraded, the install that runs for the new product is
trying to install all the features that are default selected when the
install begins. I suspect this is related to the schedule of my
SetOLDAPPFOUND action relative to MigrateFeatureStates. Can anyone tell
me if my suspicions are correct. Would changing the schedule of these
two actions relative to one another make it so it would only install the
same features for the new app as it had for the old one?
Thanks,
Amy
Amy Rosewater VanMatre
SPECTRUM Human Resource Systems Corporation
707 17th Street Suite 3800
Denver CO, 80202
303.592.3403
arosewa...@spectrumhr.com
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day
trial. Simplify your report design, integration and deployment - and
focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Let Crystal Reports handle
Re: [WiX-users] Starting another install at the end of a WIXinstaller
http://www.tramontana.co.hu/wix/lesson8.php#8.6 search the archives -Original Message- From: Radhakrishnan Meiappan [mailto:rmeiap...@datacert.com] Sent: Wednesday, September 02, 2009 11:54 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Starting another install at the end of a WIXinstaller Thanks. I can't find the 'launch after install' pattern in the tutorial nor in the user-list archive. Can you send me the url to either one of those. RK Meiappan -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, September 02, 2009 1:14 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Starting another install at the end of a WIXinstaller These installers are still for your office? Do you always distribute them in such a fashion as to have UI from the MSIs shown to the user? If so, you could try adapting the launch after install pattern mentioned in the tutorial and this list. -Original Message- From: Radhakrishnan Meiappan [mailto:rmeiap...@datacert.com] Sent: Wednesday, September 02, 2009 9:44 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Starting another install at the end of a WIX installer We use wix to create installers for our product in our office. Now, I have to call or trigger another third party installer (an .exe file) after my wix installer has finished installing. Are there any hooks in wix that will let me do something like that ? Any advise that will point me in the right direction will be very helpful. Thanks RK Meiappan. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] packa...@installerversion
It wasn't obvious to me that the PageCountSummary property is the same as the packa...@installerversion property. I admit I am new to WiX, but I think it might be beneficial if there were a more direct linking between the two properties, or at least the documentation for the two properties. Still, I would like to thank you for the help and clarification. -SteveL p.s. Searching the WiX documentation for Page Count Summary or PageCountSummary returns no hits. Similarly, searching the MSDN documentation for InstallerVersion returns lots of hits, but as far as I can tell all of those hits are examples, not property-specific documentation. -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, September 01, 2009 12:34 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] packa...@installerversion From http://msdn.microsoft.com/en-us/library/aa370570(VS.85).aspx (the link I sent earlier) The Page Count Summary property contains the minimum installer version required by the installation package. For a minimum of Windows Installer 2.0, this property must be set to the integer 200. For a minimum of Windows Installer 3.0, this property must be set to the integer 300. For a minimum of Windows Installer 3.1, this property must be set to 301. For a minimum of Windows Installer 4.5, this property must be set to 405. For a minimum of Windows Installer 5.0, this property must be set to 500. This one paragraph answers both of your questions, Steve. -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: Tuesday, September 01, 2009 10:22 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] packa...@installerversion I thought this property is used to enforce the minimum version of Windows Installer required to run the MSI. Yes that is correct. The number is calculated as major * 100 + minor. So 2.0 is 200, 3.0 is 300, 4.5 is 405 and 5.0 is 500. Neil -Original Message- From: Steve Lessard [mailto:sless...@microsoft.com] Sent: 01 September 2009 10:32 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] packa...@installerversion Maybe I am have the wrong impression of what this property is used for. I thought this property is used to enforce the minimum version of Windows Installer required to run the MSI. Is that not correct? If it is correct, what are the possible values for currently released versions of Windows Installer? In most examples I've found the values are 200 or 300. Is 450 the correct value for Windows Installer 4.5? Is 500 the correct value for Windows Installer 5.0? -Original Message- From: Blair [mailto:os...@live.com] Sent: Monday, August 31, 2009 8:51 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] packa...@installerversion The Package element populates the MSI's Summary Information Stream. The InstallerVersion attribute populates the Page Count Summary Property (http://msdn.microsoft.com/en-us/library/aa370570(VS.85).aspx) (aka, the Minimum Installer Version) of MSI files. According to (http://msdn.microsoft.com/en-us/library/aa372045(VS.85).aspx) it is of type VT_I4 (aka 32-bit signed integer). -Original Message- From: Steve Lessard [mailto:sless...@microsoft.com] Sent: Monday, August 31, 2009 6:54 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] packa...@installerversion -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list
Re: [WiX-users] hoping for confirmation
There's no connection between the property you put in your Upgrade entries and
what actually happens. I'm really very sure that OLDAPPFOUND is for your
information only - it doesn't drive anything, so changing it won't affect
anything.
What you need to arrange is as previously suggested, have MigrateFeatureStates
set in the Upgrade entry for only that product you want to migrate the features
from. But your OLDAPPFOUND has a list of products, and that makes me think you
need more Upgrade entries.
It might help if you posted your upgrade Xml.
Phil Wilson
-Original Message-
From: Amy Rosewater [mailto:arosewa...@spectrumhr.com]
Sent: Wednesday, September 02, 2009 12:16 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] hoping for confirmation
OK, so now I have MigrateFeatureStates actually doing something.
However, it is still attempting to migrate the features states from all
of the installed instances of my application. The property listed in my
Upgrade table to use for storing the product codes to upgrade is
OLDAPPFOUND. The action to set this to the single product code I am
interested in upgrading is SetOLDAPPFOUND, which is running directly
before MigrateFeatureStates. From the verbose log:
Action 12:55:16: SetOLDAPPFOUND.
Action start 12:55:16: SetOLDAPPFOUND.
MSI (c) (54:FC) [12:55:16:640]: PROPERTY CHANGE: Modifying OLDAPPFOUND
property. Its current value is
'{20ED61C2-44DA-4CD4-AD05-DBE0F7ACAE7C};{1479021E-2170-497D-B05A-A4BFE94
0A624};{009EC31E-E7DE-463B-94EB-9D24623563D8};{F3E31D03-45F2-4733-B5C0-0
A4ED7B0D023};{23A8B2E0-6BF3-4369-A55F-6230744351DE};{82D91CB2-0C1E-4AAB-
949B-221F7EF4C12F}'. Its new value:
'{009EC31E-E7DE-463B-94EB-9D24623563D8}'.
Action ended 12:55:16: SetOLDAPPFOUND. Return value 1.
MSI (c) (54:FC) [12:55:16:641]: Doing action: MigrateFeatureStates
Action 12:55:16: MigrateFeatureStates. Migrating feature states from
related applications
Action start 12:55:16: MigrateFeatureStates.
MSI (c) (54:FC) [12:55:16:641]: Migrating feature settings from
product(s)
'{20ED61C2-44DA-4CD4-AD05-DBE0F7ACAE7C};{1479021E-2170-497D-B05A-A4BFE94
0A624};{009EC31E-E7DE-463B-94EB-9D24623563D8};{F3E31D03-45F2-4733-B5C0-0
A4ED7B0D023};{23A8B2E0-6BF3-4369-A55F-6230744351DE};{82D91CB2-0C1E-4AAB-
949B-221F7EF4C12F}'
As you can see, although the OLDAPPFOUND property is set to the single
guid for the specific instance I care about, the MigrateFeatureStates
action is still using the list of guids detected during
FindRelatedProducts.
Any idea how I can change that list MigrateFeatureStates is working
with?
Thanks again!
Amy
-Original Message-
From: Amy Rosewater [mailto:arosewa...@spectrumhr.com]
Sent: Tuesday, September 01, 2009 1:04 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] hoping for confirmation
Ah thank you! I knew I must be missing something simple.
Amy
-Original Message-
From: Alexander Shevchuk (Volt) [mailto:a-ale...@microsoft.com]
Sent: Tuesday, September 01, 2009 11:29 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] hoping for confirmation
Hi Amy,
Did you set UpgradeVersion/@MigrateFeatures to yes on product you want
to upgrade?
Alex
-Original Message-
From: Amy Rosewater [mailto:arosewa...@spectrumhr.com]
Sent: Tuesday, September 01, 2009 9:28 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] hoping for confirmation
Hi All,
I am working on some minor issues in a major upgrade. :) I was hoping
someone could tell me a little about the MigrateFeatureStates action
when you have an installer that permits multiple embedded transforms of
the product code.
My install is in wix v3. I have a custom action which modifies the
property I use to keep track of the product codes of already installed
applications (in the Upgrade table). My property is OLDAPPFOUND. With
verbose logging, I can see that the OLDAPPFOUND property gets set to a
series of product codes, one for each installed instance of my
application. However, since I want to only upgrade one specific
instance, I later set the OLDAPPFOUND property to the product code for
the specific instance I want to upgrade. This definitely works as I
want.
However, currently, I have my custom action SetOLDAPPFOUND scheduled
after MigrateFeatureStates in the InstallExecuteSequence. The result
seems to be that despite what features were selected for install in the
product being upgraded, the install that runs for the new product is
trying to install all the features that are default selected when the
install begins. I suspect this is related to the schedule of my
SetOLDAPPFOUND action relative to MigrateFeatureStates. Can anyone tell
me if my suspicions are correct. Would changing the schedule of these
two actions relative to one another make it so it would only install the
same features for the new app as it had for the old one?
Re: [WiX-users] hoping for confirmation
MigrateFeatureStates checks records in the Upgrade table. It completely
ignores your OLDAPPFOUND property. This property is just for use in conditions.
Also, keep in mind that usage of MigrateFeatureState is limited
(http://msdn.microsoft.com/en-us/library/aa370034(VS.85).aspx):
... The method is only useful when the new feature tree has not greatly
changed from the original.
I am not sure I completely understand you scenario, but it looks like you need:
- separate property for each product being upgraded
- schedule FindRelatedProducts before InstallValidate
- Set conditions on features appropriately using Upgrade table properties or
run custom action(s) to get the installed features and update
ADDLOCAL/ADDSOURCE (haven't tried the ADDLOCAL/ADDSOURCE approach - need to be
tested).
-Original Message-
From: Amy Rosewater [mailto:arosewa...@spectrumhr.com]
Sent: Wednesday, September 02, 2009 12:16 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] hoping for confirmation
OK, so now I have MigrateFeatureStates actually doing something.
However, it is still attempting to migrate the features states from all
of the installed instances of my application. The property listed in my
Upgrade table to use for storing the product codes to upgrade is
OLDAPPFOUND. The action to set this to the single product code I am
interested in upgrading is SetOLDAPPFOUND, which is running directly
before MigrateFeatureStates. From the verbose log:
Action 12:55:16: SetOLDAPPFOUND.
Action start 12:55:16: SetOLDAPPFOUND.
MSI (c) (54:FC) [12:55:16:640]: PROPERTY CHANGE: Modifying OLDAPPFOUND
property. Its current value is
'{20ED61C2-44DA-4CD4-AD05-DBE0F7ACAE7C};{1479021E-2170-497D-B05A-A4BFE94
0A624};{009EC31E-E7DE-463B-94EB-9D24623563D8};{F3E31D03-45F2-4733-B5C0-0
A4ED7B0D023};{23A8B2E0-6BF3-4369-A55F-6230744351DE};{82D91CB2-0C1E-4AAB-
949B-221F7EF4C12F}'. Its new value:
'{009EC31E-E7DE-463B-94EB-9D24623563D8}'.
Action ended 12:55:16: SetOLDAPPFOUND. Return value 1.
MSI (c) (54:FC) [12:55:16:641]: Doing action: MigrateFeatureStates
Action 12:55:16: MigrateFeatureStates. Migrating feature states from
related applications
Action start 12:55:16: MigrateFeatureStates.
MSI (c) (54:FC) [12:55:16:641]: Migrating feature settings from
product(s)
'{20ED61C2-44DA-4CD4-AD05-DBE0F7ACAE7C};{1479021E-2170-497D-B05A-A4BFE94
0A624};{009EC31E-E7DE-463B-94EB-9D24623563D8};{F3E31D03-45F2-4733-B5C0-0
A4ED7B0D023};{23A8B2E0-6BF3-4369-A55F-6230744351DE};{82D91CB2-0C1E-4AAB-
949B-221F7EF4C12F}'
As you can see, although the OLDAPPFOUND property is set to the single
guid for the specific instance I care about, the MigrateFeatureStates
action is still using the list of guids detected during
FindRelatedProducts.
Any idea how I can change that list MigrateFeatureStates is working
with?
Thanks again!
Amy
-Original Message-
From: Amy Rosewater [mailto:arosewa...@spectrumhr.com]
Sent: Tuesday, September 01, 2009 1:04 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] hoping for confirmation
Ah thank you! I knew I must be missing something simple.
Amy
-Original Message-
From: Alexander Shevchuk (Volt) [mailto:a-ale...@microsoft.com]
Sent: Tuesday, September 01, 2009 11:29 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] hoping for confirmation
Hi Amy,
Did you set UpgradeVersion/@MigrateFeatures to yes on product you want
to upgrade?
Alex
-Original Message-
From: Amy Rosewater [mailto:arosewa...@spectrumhr.com]
Sent: Tuesday, September 01, 2009 9:28 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] hoping for confirmation
Hi All,
I am working on some minor issues in a major upgrade. :) I was hoping
someone could tell me a little about the MigrateFeatureStates action
when you have an installer that permits multiple embedded transforms of
the product code.
My install is in wix v3. I have a custom action which modifies the
property I use to keep track of the product codes of already installed
applications (in the Upgrade table). My property is OLDAPPFOUND. With
verbose logging, I can see that the OLDAPPFOUND property gets set to a
series of product codes, one for each installed instance of my
application. However, since I want to only upgrade one specific
instance, I later set the OLDAPPFOUND property to the product code for
the specific instance I want to upgrade. This definitely works as I
want.
However, currently, I have my custom action SetOLDAPPFOUND scheduled
after MigrateFeatureStates in the InstallExecuteSequence. The result
seems to be that despite what features were selected for install in the
product being upgraded, the install that runs for the new product is
trying to install all the features that are default selected when the
install begins. I suspect this is related to the schedule of my
SetOLDAPPFOUND action relative to
Re: [WiX-users] hoping for confirmation
I am not sure what you mean by have MigrateFeatureStates set in the
Upgrade entry for only that product you want to migrate the features
from.
I have the following for my upgrade xml:
Upgrade Id=40e665b9-9825-4b2b-b3e1-ebf6082e57a4
UpgradeVersion Property=OLDAPPFOUND IgnoreRemoveFailure=no
IncludeMinimum=yes Minimum=5.0.0.0 IncludeMaximum=no
Maximum=5.3.0.0 Language=1033 MigrateFeatures=yes /
UpgradeVersion Property=NEWAPPFOUND IncludeMinimum=no
OnlyDetect=yes Minimum=5.3.0.0 Language=1033 /
/Upgrade
To be clear about how I am making all this work, I have embedded
transforms of the product code to support multiple side by side
installations of our application. I also have a bootstrapper
application which presents a list of installed instances for the user,
and then builds the appropriate command line string to pass to msiexec
based on the instance selected. If the instance is older than the
current version, it permits an upgrade, and passes in the product code
for the instance the user selected which is what I use to set
OLDAPPFOUND. This value is definitely utilized by
RemoveExistingProducts as it only uninstalls the product matching the
product code in OLDAPPFOUND.
I have definitely reached the edge of my windows installer knowledge
here... :)
Thanks again for your help!
Amy
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@wonderware.com]
Sent: Wednesday, September 02, 2009 1:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] hoping for confirmation
There's no connection between the property you put in your Upgrade
entries and what actually happens. I'm really very sure that OLDAPPFOUND
is for your information only - it doesn't drive anything, so changing it
won't affect anything.
What you need to arrange is as previously suggested, have
MigrateFeatureStates set in the Upgrade entry for only that product you
want to migrate the features from. But your OLDAPPFOUND has a list of
products, and that makes me think you need more Upgrade entries.
It might help if you posted your upgrade Xml.
Phil Wilson
-Original Message-
From: Amy Rosewater [mailto:arosewa...@spectrumhr.com]
Sent: Wednesday, September 02, 2009 12:16 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] hoping for confirmation
OK, so now I have MigrateFeatureStates actually doing something.
However, it is still attempting to migrate the features states from all
of the installed instances of my application. The property listed in my
Upgrade table to use for storing the product codes to upgrade is
OLDAPPFOUND. The action to set this to the single product code I am
interested in upgrading is SetOLDAPPFOUND, which is running directly
before MigrateFeatureStates. From the verbose log:
Action 12:55:16: SetOLDAPPFOUND.
Action start 12:55:16: SetOLDAPPFOUND.
MSI (c) (54:FC) [12:55:16:640]: PROPERTY CHANGE: Modifying OLDAPPFOUND
property. Its current value is
'{20ED61C2-44DA-4CD4-AD05-DBE0F7ACAE7C};{1479021E-2170-497D-B05A-A4BFE94
0A624};{009EC31E-E7DE-463B-94EB-9D24623563D8};{F3E31D03-45F2-4733-B5C0-0
A4ED7B0D023};{23A8B2E0-6BF3-4369-A55F-6230744351DE};{82D91CB2-0C1E-4AAB-
949B-221F7EF4C12F}'. Its new value:
'{009EC31E-E7DE-463B-94EB-9D24623563D8}'.
Action ended 12:55:16: SetOLDAPPFOUND. Return value 1.
MSI (c) (54:FC) [12:55:16:641]: Doing action: MigrateFeatureStates
Action 12:55:16: MigrateFeatureStates. Migrating feature states from
related applications
Action start 12:55:16: MigrateFeatureStates.
MSI (c) (54:FC) [12:55:16:641]: Migrating feature settings from
product(s)
'{20ED61C2-44DA-4CD4-AD05-DBE0F7ACAE7C};{1479021E-2170-497D-B05A-A4BFE94
0A624};{009EC31E-E7DE-463B-94EB-9D24623563D8};{F3E31D03-45F2-4733-B5C0-0
A4ED7B0D023};{23A8B2E0-6BF3-4369-A55F-6230744351DE};{82D91CB2-0C1E-4AAB-
949B-221F7EF4C12F}'
As you can see, although the OLDAPPFOUND property is set to the single
guid for the specific instance I care about, the MigrateFeatureStates
action is still using the list of guids detected during
FindRelatedProducts.
Any idea how I can change that list MigrateFeatureStates is working
with?
Thanks again!
Amy
-Original Message-
From: Amy Rosewater [mailto:arosewa...@spectrumhr.com]
Sent: Tuesday, September 01, 2009 1:04 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] hoping for confirmation
Ah thank you! I knew I must be missing something simple.
Amy
-Original Message-
From: Alexander Shevchuk (Volt) [mailto:a-ale...@microsoft.com]
Sent: Tuesday, September 01, 2009 11:29 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] hoping for confirmation
Hi Amy,
Did you set UpgradeVersion/@MigrateFeatures to yes on product you want
to upgrade?
Alex
-Original Message-
From: Amy Rosewater [mailto:arosewa...@spectrumhr.com]
Sent: Tuesday, September 01, 2009 9:28 AM
To: General discussion for Windows Installer
Re: [WiX-users] Patch failure on XP that doesn't happen on Vista
I tried installing Windows Installer version 4.5 on XP machine but that didn't fix the problem. What fixed it is quite scary because of the hacky method that was used. In short, copying Vista version 6.0 of MSPATCHA.DLL (from System32 folder) to XP, which had version 5.1 of it, made patching succeed as it did on Vista machine. The file that previously crashed the patching process before was now correctly patched and as the result had a new version. However, MSPATCHA.DLL is a protected DLL and I had to disable XP file system protection in order to install newer Vista version 6.0. This means changing Registry value while kernel debugger is attached via null modem cable. Clearly, this is no way that I can fix the issue on customer's XP machines. I feel that Microsoft should provide a safe way of updating buggy MSPATCHA.DLL on XP machines. -Original Message- From: Tony Juricic Sent: Wednesday, September 02, 2009 7:37 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista I am using PatchWiz. Also, I am afraid I don't understand if I should use IgnoreRange, if I could do it with PatchWiz. On XP the patching system thinks that file has been already patched which is simply wrong, even if the difference is probably only in version resource part of the file. It also aborts the patching process and rolls back all the changes. I can't patch the entire system anymore because of this error. I would rather see the same behavior as in Vista where the same file gets patched and I see it got a new version when looking at its properties in Explorer. Thus I am thinking either play with installer versions, of which XP one appears to be buggy, or take your suggestion to include the entire file in the patch, rather than using differences. -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, September 02, 2009 1:13 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista TargetFile\IgnoreRange element(s) are intended for exactly your scenario (you tell the system one or more sections of the binary that don't matter for it to be able to assert that the file is the same before applying the patch it). If you are using Pyro instead of PatchWiz, the IgnoreRange element goes under the File element in building your Updated image (it seems to be missing from the schema/help doc). -Original Message- From: Tony Juricic [mailto:tjuri...@tradestation.com] Sent: Tuesday, September 01, 2009 6:08 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista Hi Blair, Actually, the files are not bit-for-bit the same. The error message is probably too generic and misleading in this case. In the case of this particular file there are no changes in code and the only difference is in version resource which has 4-th version number different from the RTM version. IMO, that explains why PatchSize=6113,TargetSize=100198. This is nothing unusual considering the build system that I am using, which increments 4-th version number with each new build. Quite a few other files have the same differences - just version resource - and they don't exhibit this problem. I build MSP on Server 2003 system with MSI version 3.01.4000.3959 and I create only Release build patches. It seems that patch application MSI version is more important than the build system MSI version since patch applies without a glitch on Vista with version V 4.5.6002.18005 MSI, while it fails on XP with MSI components version 3.01. I guess I would have to enforce both build and application MSI versions to be the same (meaning I'll have to install 4.5 MSI on XP machines before staring install and patching process), but at this time it is just a guess. Thanks, Tony -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, September 01, 2009 6:20 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista I assumed you verified that the files are bit-for-bit the same before attempting to apply the patch. Do you build your MSP on a Vista/Server 2008 system? We saw this one time and it happened only with Release (not Debug) for just one file, but didn't happen when building on XP/32-bit (I never investigated building on either 64-bit XP or Server 2003). Our products were not allowed on Server OSs but we did our official builds on them. It seems that the PatchAPI binaries (described here: http://msdn.microsoft.com/en-us/library/bb417345.aspx) are somehow different and the Patch Apply routines are somehow sometimes different between platforms. For a workaround we had to mark that one file as whole file instead of delta. It didn't happen every build, but it did happen for about two
Re: [WiX-users] Patch failure on XP that doesn't happen on Vista
Alternately try building with version 5.1 of MSPATCHC.DLL (by building on an XP box?). -Original Message- From: Tony Juricic [mailto:tjuri...@tradestation.com] Sent: Wednesday, September 02, 2009 1:36 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista I tried installing Windows Installer version 4.5 on XP machine but that didn't fix the problem. What fixed it is quite scary because of the hacky method that was used. In short, copying Vista version 6.0 of MSPATCHA.DLL (from System32 folder) to XP, which had version 5.1 of it, made patching succeed as it did on Vista machine. The file that previously crashed the patching process before was now correctly patched and as the result had a new version. However, MSPATCHA.DLL is a protected DLL and I had to disable XP file system protection in order to install newer Vista version 6.0. This means changing Registry value while kernel debugger is attached via null modem cable. Clearly, this is no way that I can fix the issue on customer's XP machines. I feel that Microsoft should provide a safe way of updating buggy MSPATCHA.DLL on XP machines. -Original Message- From: Tony Juricic Sent: Wednesday, September 02, 2009 7:37 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista I am using PatchWiz. Also, I am afraid I don't understand if I should use IgnoreRange, if I could do it with PatchWiz. On XP the patching system thinks that file has been already patched which is simply wrong, even if the difference is probably only in version resource part of the file. It also aborts the patching process and rolls back all the changes. I can't patch the entire system anymore because of this error. I would rather see the same behavior as in Vista where the same file gets patched and I see it got a new version when looking at its properties in Explorer. Thus I am thinking either play with installer versions, of which XP one appears to be buggy, or take your suggestion to include the entire file in the patch, rather than using differences. -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, September 02, 2009 1:13 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista TargetFile\IgnoreRange element(s) are intended for exactly your scenario (you tell the system one or more sections of the binary that don't matter for it to be able to assert that the file is the same before applying the patch it). If you are using Pyro instead of PatchWiz, the IgnoreRange element goes under the File element in building your Updated image (it seems to be missing from the schema/help doc). -Original Message- From: Tony Juricic [mailto:tjuri...@tradestation.com] Sent: Tuesday, September 01, 2009 6:08 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista Hi Blair, Actually, the files are not bit-for-bit the same. The error message is probably too generic and misleading in this case. In the case of this particular file there are no changes in code and the only difference is in version resource which has 4-th version number different from the RTM version. IMO, that explains why PatchSize=6113,TargetSize=100198. This is nothing unusual considering the build system that I am using, which increments 4-th version number with each new build. Quite a few other files have the same differences - just version resource - and they don't exhibit this problem. I build MSP on Server 2003 system with MSI version 3.01.4000.3959 and I create only Release build patches. It seems that patch application MSI version is more important than the build system MSI version since patch applies without a glitch on Vista with version V 4.5.6002.18005 MSI, while it fails on XP with MSI components version 3.01. I guess I would have to enforce both build and application MSI versions to be the same (meaning I'll have to install 4.5 MSI on XP machines before staring install and patching process), but at this time it is just a guess. Thanks, Tony -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, September 01, 2009 6:20 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista I assumed you verified that the files are bit-for-bit the same before attempting to apply the patch. Do you build your MSP on a Vista/Server 2008 system? We saw this one time and it happened only with Release (not Debug) for just one file, but didn't happen when building on XP/32-bit (I never investigated building on either 64-bit XP or Server 2003). Our products were not allowed on Server OSs but we did our official builds on them. It seems that the
[WiX-users] Setting Property Values After Custom Dialog
Hi, I have created a custom dialog that executes during my installation where the user selects the environment (TEST, QA, or PROD) that they are installing into via a radio button, and this radio button is bound to a property in my installer. I would like to update some other properties in my installer based on the user's selection. I thought I could accomplish this using a SetProperty element with a condition, but I can't seem to find the right action to bind the Before or After attribute to. I keep getting the error Found an ActionRow with a non-existent Before/After action from light.exe. Am I doing something wrong? Is this even possible? If so, how can I accomplish this? Thanks, Nathan Roe Software Engineer II Software Engineering Professionals 11611 N. Meridian Street - 8th Floor Carmel, IN 46032-4609 317.843.1640 Ext. 2082 317.843.1642 (fax) nd...@sep.commailto:nd...@sep.com - www.sep.comhttp://www.sep.com/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] hoping for confirmation
So it looks like Amy's multiple products all have the same UpgradeCode,
different ProductCodes.
If they also all have the same ProductVersion then there's no way to
distinguish one from another in the Upgrade table. The kind of thing needed is
either:
a) Multiple upgrade codes for the installed products. Then your Upgrade entries
are one per unique UpgradeCode, and the installed product that you want to
migrate features from (identified by its unique UpgradeCode) is the only one
with migrate features set true.
b) Multiple Upgrade entries where the UpgradeCodes are all the same but each
targets a different version. All the installed products have the same
ProductCode but different versions, so you make upgrade entries where the
ProductVersion you want to migrate features from is the only one with migrate
features set true.
So as I said, if it's true that all the transformed products have the same
UpgradeCode and the same ProductVersions then there's no mechanism in the
Upgrade table definition to search for the one product that you do want to
migrate features from, and you'll need something like Alex's solution.
Phil Wilson
-Original Message-
From: Alexander Shevchuk (Volt) [mailto:a-ale...@microsoft.com]
Sent: Wednesday, September 02, 2009 1:24 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] hoping for confirmation
MigrateFeatureStates checks records in the Upgrade table. It completely
ignores your OLDAPPFOUND property. This property is just for use in conditions.
Also, keep in mind that usage of MigrateFeatureState is limited
(http://msdn.microsoft.com/en-us/library/aa370034(VS.85).aspx):
... The method is only useful when the new feature tree has not greatly
changed from the original.
I am not sure I completely understand you scenario, but it looks like you need:
- separate property for each product being upgraded
- schedule FindRelatedProducts before InstallValidate
- Set conditions on features appropriately using Upgrade table properties or
run custom action(s) to get the installed features and update
ADDLOCAL/ADDSOURCE (haven't tried the ADDLOCAL/ADDSOURCE approach - need to be
tested).
-Original Message-
From: Amy Rosewater [mailto:arosewa...@spectrumhr.com]
Sent: Wednesday, September 02, 2009 12:16 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] hoping for confirmation
OK, so now I have MigrateFeatureStates actually doing something.
However, it is still attempting to migrate the features states from all
of the installed instances of my application. The property listed in my
Upgrade table to use for storing the product codes to upgrade is
OLDAPPFOUND. The action to set this to the single product code I am
interested in upgrading is SetOLDAPPFOUND, which is running directly
before MigrateFeatureStates. From the verbose log:
Action 12:55:16: SetOLDAPPFOUND.
Action start 12:55:16: SetOLDAPPFOUND.
MSI (c) (54:FC) [12:55:16:640]: PROPERTY CHANGE: Modifying OLDAPPFOUND
property. Its current value is
'{20ED61C2-44DA-4CD4-AD05-DBE0F7ACAE7C};{1479021E-2170-497D-B05A-A4BFE94
0A624};{009EC31E-E7DE-463B-94EB-9D24623563D8};{F3E31D03-45F2-4733-B5C0-0
A4ED7B0D023};{23A8B2E0-6BF3-4369-A55F-6230744351DE};{82D91CB2-0C1E-4AAB-
949B-221F7EF4C12F}'. Its new value:
'{009EC31E-E7DE-463B-94EB-9D24623563D8}'.
Action ended 12:55:16: SetOLDAPPFOUND. Return value 1.
MSI (c) (54:FC) [12:55:16:641]: Doing action: MigrateFeatureStates
Action 12:55:16: MigrateFeatureStates. Migrating feature states from
related applications
Action start 12:55:16: MigrateFeatureStates.
MSI (c) (54:FC) [12:55:16:641]: Migrating feature settings from
product(s)
'{20ED61C2-44DA-4CD4-AD05-DBE0F7ACAE7C};{1479021E-2170-497D-B05A-A4BFE94
0A624};{009EC31E-E7DE-463B-94EB-9D24623563D8};{F3E31D03-45F2-4733-B5C0-0
A4ED7B0D023};{23A8B2E0-6BF3-4369-A55F-6230744351DE};{82D91CB2-0C1E-4AAB-
949B-221F7EF4C12F}'
As you can see, although the OLDAPPFOUND property is set to the single
guid for the specific instance I care about, the MigrateFeatureStates
action is still using the list of guids detected during
FindRelatedProducts.
Any idea how I can change that list MigrateFeatureStates is working
with?
Thanks again!
Amy
-Original Message-
From: Amy Rosewater [mailto:arosewa...@spectrumhr.com]
Sent: Tuesday, September 01, 2009 1:04 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] hoping for confirmation
Ah thank you! I knew I must be missing something simple.
Amy
-Original Message-
From: Alexander Shevchuk (Volt) [mailto:a-ale...@microsoft.com]
Sent: Tuesday, September 01, 2009 11:29 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] hoping for confirmation
Hi Amy,
Did you set UpgradeVersion/@MigrateFeatures to yes on product you want
to upgrade?
Alex
-Original Message-
From: Amy Rosewater
Re: [WiX-users] How to add a dialog box when uninstall
Hi Blair, I really appreciate your efforts on this issue. Yes, how maintenance-mode UI is supposed to work? - This is the question I'd ask. So anyone, if you happen to know how maintenance-mode UI is supposed to work or any useful link as you know of, please let me know. Thanks you all! /Brian From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Tuesday, September 1, 2009 10:34:28 PM Subject: Re: [WiX-users] How to add a dialog box when uninstall Maybe there is a bug in the WiXUI. I have never used WiX's UI in any product I've shipped, and we recently started shipping languages that Windows Installer's UI doesn't support very well at all, so we dropped in-MSI UI entirely when we went with bootstrappers to manage our UI in a unified way for our suite (similar to what Office and Developer Division at MSFT had already done). Looking closely at the source code, I don't see the expected EndDialog publish event. The Property is set from pushing the Remove button and something is supposed to register that as a REMOVE=ALL type setting (eventually) but Next is disabled in that window and no other events seem to be triggered looking at the source code.. I need to push this back to the WiX team to see who knows how WiXUI is put together and how maintenance-mode UI is supposed to work. -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Tuesday, September 01, 2009 4:23 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to add a dialog box when uninstall The mail was sent before it was finished. Let me continue. Ok, I went a little trouble to get the MaintenanceTypeDlg.wxs from the Wix source and put it in my project. I renamed it as MyMaintenanceTypeDlg.wxs. Then I removed this line: Condition Action=disableARPNOREMOVE/Condition I also changed MyWixUI_InstallDir.wxs for this line to use the changed MaintenanceTypeDlg: Publish Dialog=MaintenanceWelcomeDlg Control=Next Event=NewDialog Value=MyMaintenanceTypeDlg1/Publish Then I compiled and run. I did see the [Remove] button, but when I clicked on it, nothing happened. Here is the InstallUISequence table from msi: AppSearch50 CostInitialize800 FileCost900 CostFinalize1000 FatalError-3 UserExit-2 MyExitDialog-1 ExecuteAction1300 PrepareDlg49 ProgressDlg1299 ResumeDlgInstalled AND (RESUME OR Preselected)1297 WelcomeDlgNOT Installed1298 MaintenanceWelcomeDlgInstalled AND NOT RESUME AND NOT Preselected1296 NewerVersionDetectedNEWAPPFOUND201 LaunchConditions100 FindRelatedProducts200 ValidateProductID700 Here is the log when I uninstalled it: MSI (c) (94:B8) [16:20:58:774]: Doing action: MaintenanceWelcomeDlg MSI (c) (94:B8) [16:20:58:774]: Note: 1: 2205 2: 3: ActionText Action 16:20:58: MaintenanceWelcomeDlg. Action start 16:20:58: MaintenanceWelcomeDlg. Action 16:20:58: MaintenanceWelcomeDlg. Dialog created MSI (c) (94:CC) [16:20:58:852]: PROPERTY CHANGE: Modifying CostingComplete property. Its current value is '0'. Its new value: '1'. MSI (c) (94:CC) [16:20:58:852]: Note: 1: 2205 2: 3: BindImage MSI (c) (94:CC) [16:20:58:852]: Note: 1: 2205 2: 3: ProgId MSI (c) (94:CC) [16:20:58:852]: Note: 1: 2205 2: 3: PublishComponent MSI (c) (94:CC) [16:20:58:852]: Note: 1: 2205 2: 3: SelfReg MSI (c) (94:CC) [16:20:58:852]: Note: 1: 2205 2: 3: Extension MSI (c) (94:CC) [16:20:58:852]: Note: 1: 2205 2: 3: Font MSI (c) (94:CC) [16:20:58:852]: Note: 1: 2205 2: 3: Class MSI (c) (94:CC) [16:20:58:852]: Note: 1: 2727 2: MSI (c) (94:CC) [16:20:59:727]: Note: 1: 2205 2: 3: Error MSI (c) (94:CC) [16:20:59:727]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 2898 Info 2898. WixUI_Font_Title, Tahoma, 1 Action 16:20:59: MyMaintenanceTypeDlg. Dialog created MSI (c) (94:CC) [16:21:01:805]: PROPERTY CHANGE: Adding WixUI_InstallMode property. Its value is 'Remove'. Action 16:21:04: CancelDlg. Dialog created Action ended 16:21:05: MaintenanceWelcomeDlg. Return value 2. MSI (c) (94:B8) [16:21:05:446]: Doing action: UserExit MSI (c) (94:B8) [16:21:05:446]: Note: 1: 2205 2: 3: ActionText Action 16:21:05: UserExit. Action start 16:21:05: UserExit. Action 16:21:05: UserExit. Dialog created Action ended 16:21:06: UserExit. Return value 2. Action ended 16:21:06: INSTALL. Return value 2. Thanks. From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Tuesday, September 1, 2009 3:25:49 PM Subject: Re: [WiX-users] How to add a dialog box when uninstall In your copy of MaintenanceTypeDlg.wxs remove the condition on the Remove button. That is the button you want to click to uninstall from the UI. -Original
Re: [WiX-users] Patch failure on XP that doesn't happen on Vista
I will try that. However, the sole reason for my using MSPATCHC.DLL 6.0 was because PatchWiz.dll version before 4.0 had other patching problems which were reported to be solved by PatchWiz.dll version 4.0 and above. So I used SDK 6.0 version of PatchWiz.dll which is 4.0 and it comes with 6.0 version of MSPATCHC.DLL. So, should I use PatchWiz.dll 4.0 and above with MSPATCHC.DLL 5.1 and hope for the best? Apparently, Microsoft considers that they have no responsibility to document, explain, fix or support any of these issues. Where was the testing? If I can break patching just in a few builds that mostly change version resources, how reliable was testing of that software? The message seems to be: It is up to you, dear foolish Microsoft developer, to try and use our patch/differencing/compression system, and if you end up in trouble there is nobody who gives a damn. Experiment and try this or that. Maybe it works, maybe it doesn't. Microsoft developers who developed this system and their managers feel no obligation to provide any support or guidance. -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, September 02, 2009 4:52 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista Alternately try building with version 5.1 of MSPATCHC.DLL (by building on an XP box?). -Original Message- From: Tony Juricic [mailto:tjuri...@tradestation.com] Sent: Wednesday, September 02, 2009 1:36 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista I tried installing Windows Installer version 4.5 on XP machine but that didn't fix the problem. What fixed it is quite scary because of the hacky method that was used. In short, copying Vista version 6.0 of MSPATCHA.DLL (from System32 folder) to XP, which had version 5.1 of it, made patching succeed as it did on Vista machine. The file that previously crashed the patching process before was now correctly patched and as the result had a new version. However, MSPATCHA.DLL is a protected DLL and I had to disable XP file system protection in order to install newer Vista version 6.0. This means changing Registry value while kernel debugger is attached via null modem cable. Clearly, this is no way that I can fix the issue on customer's XP machines. I feel that Microsoft should provide a safe way of updating buggy MSPATCHA.DLL on XP machines. -Original Message- From: Tony Juricic Sent: Wednesday, September 02, 2009 7:37 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista I am using PatchWiz. Also, I am afraid I don't understand if I should use IgnoreRange, if I could do it with PatchWiz. On XP the patching system thinks that file has been already patched which is simply wrong, even if the difference is probably only in version resource part of the file. It also aborts the patching process and rolls back all the changes. I can't patch the entire system anymore because of this error. I would rather see the same behavior as in Vista where the same file gets patched and I see it got a new version when looking at its properties in Explorer. Thus I am thinking either play with installer versions, of which XP one appears to be buggy, or take your suggestion to include the entire file in the patch, rather than using differences. -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, September 02, 2009 1:13 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista TargetFile\IgnoreRange element(s) are intended for exactly your scenario (you tell the system one or more sections of the binary that don't matter for it to be able to assert that the file is the same before applying the patch it). If you are using Pyro instead of PatchWiz, the IgnoreRange element goes under the File element in building your Updated image (it seems to be missing from the schema/help doc). -Original Message- From: Tony Juricic [mailto:tjuri...@tradestation.com] Sent: Tuesday, September 01, 2009 6:08 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista Hi Blair, Actually, the files are not bit-for-bit the same. The error message is probably too generic and misleading in this case. In the case of this particular file there are no changes in code and the only difference is in version resource which has 4-th version number different from the RTM version. IMO, that explains why PatchSize=6113,TargetSize=100198. This is nothing unusual considering the build system that I am using, which increments 4-th version number with each new build. Quite a few other files have the same differences - just version
[WiX-users] Extra Files in Patch
Hi, I am using the WiX-only approach described in the wix3 chm to create patch packages. In some cases lots of extra files (files that have not changed from the baseline version) are being included in the patch, maybe hundreds. They are not referenced in the patch.wxs file, and I have no idea how or why they got there. If I view the patch in orca, I see that the PatchAdded bit has been set on the attribute column for these files but no other differences. They seem to come from the same component group as the changed files, though. This not only makes the .msp file huge, but it will overwrite files from previous patches. Any help would be greatly appreciated. Thanks! -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
