Re: [WiX-users] How to keep guids in similar setups
Blair, We do not have shared components, shared GUIDs are used only for installer development efficiency. In some installers we have up to 15 products (with different ProductCode and PackageCode) that are built from the same source files. 15 sets of GUIDs are not as convenient as a single set. Best regards, Ilya Slobodin Blair wrote on Thu, 02 Dec 2010 13:50:04 -0800 > Do those components actually share anything (registry keys, COM > registration, > custom actions, whatever) that require them to have the same guid? > > Original Message > Subject: Re: [WiX-users] How to keep guids in similar setups > From: Ilya Slobodin > To: Mike Dimmick > Cc: 'John Vottero' , wix-users@lists.sourceforge.net > Date: 02.12.2010 21:09 > -- Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to keep guids in similar setups
Hi, Continuing the discussion after the three years. To refresh the problem: We have several products that share component GUIDs between them. These products are in fact different configurations of the same project (Pro, Demo еtc.) with the similar file list. The products are installed side by side into different directories. Everything seemed to work fine not counting the rare reports from our customers that minor update failed to update some files on Vista and 7. We have no such reports for XP. Some days ago we built the shared component list with msiinv.exe -m and found that our components with shared GUIDs are listed as shared (!) on Vista and 7 (on XP with MSI 3.1 or 4.5 the same components are not listed as shared). As a consequence, these components are not completely independent of each other and there is a configuration where minor upgrade always fails. Steps to reproduce: Install product 1 Component A ver 1.0 goes to Program Files\Product 1\A.dll Install product 2 Component A ver 1.0 goes to Program Files\Product 2\A.dll Update product 2 Component A ver 1.1 updates Program Files\Product 2\A.dll Update product 1 Component A ver 1.1 DOES NOT update Program Files\Product 1\A.dll because it is considered to have the same version. Is there a way to solve this problem on Vista and 7 other than making .wxi files with different GUIDs for each configuration. Best regards, Ilya Slobodin Original Message Subject: Re: [WiX-users] How to keep guids in similar setups From: Mike Dimmick To: 'John Vottero' , 'Ilya Slobodin' , wix-users@lists.sourceforge.net Date: 16.10.2007 2:07 > Not necessarily true. It is OK to install the same component to different > paths; it is definitely wrong to install two different components to the > same path as then the references get cross-linked. > > Windows Installer tracks where every installed product installed every > component that it installed. When removing a component, it checks to see > whether any other product is still referencing that component at the same > install path - if not, it removes it. If there is another component not > installed by that product which installed the same file, the other product > will then be broken. > > When installing and removing components, the definition from the package you > are installing or maintaining is used. That's why you have to be very > careful with adding and removing files in components. If you produce a > (shared) component with files A, B, C and D and ship product P1, then add a > new file E and ship product P2, if the user installs P1 then P2 and removes > P2 then P1, file E will be left behind because it wasn't in P1's definition > of the component. > > If you change the component GUID you _must_ move the resources. This no > doubt includes ensuring that a user doesn't install a later version to the > same folder as an old one. > > Astute readers will realise that if you're performing only major upgrades > and you remove the old product before installing the new (i.e. schedule > RemoveExistingProducts between InstallValidate and InstallInitialize), you > can break a lot of component rules for private components that aren't shared > with any other products, because the old components are wiped out before the > new ones are installed. I'm not saying you should, I'm saying you're > unlikely to suffer the consequences. Do anything more complicated, with > shared components, minor upgrades, patches, or scheduling > RemoveExistingProducts anywhere else, and you quickly run into difficulty. > It's best to do it right to begin with so it doesn't affect > -- Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch creation problems
Hi, REINSTALL=ALL REINSTALLMODE=omus are set from the UI when Repair button is pressed. Haven't you changed the test.txt before the patch is applied? My experiments show that patches are installed better without setting REINSTALL and REINSTALLMODE. If these properties are set, this can cause problems with component action state dependencies, e.g. MoveFile records. See my post "Patch install: MoveFiles and component action states" earlier in this list. There is also a sample that patches the text file. The problem is that when REINSTALL=ALL REINSTALLMODE=omus are set, action state of all components becomes "Local" but no action is really executed on the components not included in the patch. When REINSTALL=ALL REINSTALLMODE=omus are not set, action states of the files being patched are set to "Local" by the msi engine. Best regards, Ilya Slobodin - Original Message - From: "Robert O'Brien" <[EMAIL PROTECTED]> To: "'General discussion for Windows Installer XML toolset.'" Sent: Tuesday, September 23, 2008 7:23 AM Subject: Re: [WiX-users] Patch creation problems > You need to launch the msp using the command line and the properties > REINSTALL=ALL REINSTALLMODE=omus. If you want to be able to use > your msp by double clicking on it you need to add something like the > following to your wix sources so that those property values will get > assigned automatically before processing begins. > > > Property="REINSTALL" Value="ALL" /> > Id="SetMspSmallUpdateOrMinorUpgradeReInstallModeProperty" > Property="REINSTALLMODE" Value="omus" /> > > > After="LaunchConditions">PATCH And Installed > Action="SetMspSmallUpdateOrMinorUpgradeReInstallModeProperty" > After="LaunchConditions">PATCH And Installed > > > -Original Message- > From: Scott Sam [mailto:[EMAIL PROTECTED] > Sent: Monday, September 22, 2008 9:00 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Patch creation problems > > > When I double click on my msp file I get the welcome dialog, > followed > by the maintenance dialog, giving me the choice to change, repair or > remove. Choosing repair or change, will cause the patch to show up > in > add/remove programs, but the text file does not show the changes > that I > made. > > Problem 1: Why do I get the maintenance dialog? I would like to > just > double click the msp file and then have the patch be applied. Is > there > any way to do this? > Problem 2: the changes aren't being applied. How do I fix this? > > I'm using wix version 3.0.4429.0 > > To create my patch I'm using the following method: > 1. Compile original msi > 2. Change a text file that is included in the msi. > 3. Compile new msi > 4. Create a transform between the two msi's. > torch.exe -p -xi original\Product.wixpdb Product.wixpdb -out > Patch\Diff.Wixmst > 5. Build the patch > pyro.exe Patch\Patch.WixMsp -out Patch\Patch.msp -t RTM > Patch\Diff.wixmst > > here is my patch.wxs file: > > http://schemas.microsoft.com/wix/2006/wi";> > DisplayName="Test Patch" Description="Small Update Patch" > Classification="Update" MinorUpdateTargetRTM="yes"> > > > > > > > > Supersede="yes"> > > > > > > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to distinguish between "full repair" and "self-repair"?
Hi guys, How to distinguish between "full repair" from Add/Remove Programs and "self-repair" started by the shortcut for each new user when the key path of the shortcut is not found? Is the difference in the value of REINSTALLMODE is robust enough? REINSTALLMODE=ecmus -- full repair, REINSTALLMODE=pocmus -- self repair. Our product contains a big database that we cannot place inside a .cab file. In case of "full repair" we need to reinstall database, to find it from a CA we need to call ResolveSource before. And we don't want to call ResolveSource when a new user starts our product for the first time. Best regards, Ilya Slobodin - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Localization filename change
Neil, Nothing fundamental, the idea is great and I hope the next step will be the MsBuild task for language transforms. My opposition is based on general considerations on how the new builds of applications should work. I think that the new build is good when I do not need to tweak my scripts until I need the new functions in that build. What's why I call this a break of compatibility. Best regards, Ilya Slobodin - Original Message - From: "Neil Enns" <[EMAIL PROTECTED]> To: "General discussion for Windows Installer XML toolset." Sent: Monday, July 21, 2008 8:07 PM Subject: Re: [WiX-users] Localization filename change > Ilya, > > Thanks for the additional insight into how your builds work. A > follow-up question: is there something fundamental in the new > localization work that doesn't integrate into your builds, or is the > issue that the change to either a suffix or directory will require > tweaks to your existing build process to integrate properly? For > what it's worth, when I integrated this build of WiX into my own > team we had to make a few build process tweaks as well. > > Neil > > -Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ilya > Slobodin > Sent: Monday, July 21, 2008 8:30 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Localization filename change > > Hi Neil, > > We use at least two builds of WiX at the same time. Newer builds on > the development computers and older and well-tested on the > production > server. And we upgrade the server only when we need to use some new > functions. Before each upgrade we have to make sure that all our > setups are not broken. > > For our environment, the output into subdirectories is better than > culture suffix but this still is not as flexible as It could be. > > Is it possible to replace the proposed > > $(TargetDir)\CultureName\$(TargetName)$(TargetExt). > > with > > $(TargetDir)\$(CultureSuffix)\$(TargetName)$(TargetExt) > > where CultureSuffix is overridable and is empty by default when > single > culture is used? > > Or, even better, put > $(TargetDir)\$(CultureSuffix)\$(TargetName)$(TargetExt) into the > overridable property, say TargetDirLocalized. > > Best regards, > Ilya Slobodin > > - Original Message - > From: "Neil Enns" <[EMAIL PROTECTED]> > To: "General discussion for Windows Installer XML toolset." > > Sent: Monday, July 21, 2008 6:18 PM > Subject: Re: [WiX-users] Localization filename change > > >> Ilya, >> >> If we changed things so the localized output went into >> subdirectories, rather than modified the name of the MSI, would >> htat >> work for your situation? >> Neil >> >> >> From: [EMAIL PROTECTED] >> [EMAIL PROTECTED] On Behalf Of Ilya >> Slobodin >> [EMAIL PROTECTED] >> Sent: Monday, July 21, 2008 1:59 AM >> To: General discussion for Windows Installer XML toolset. >> Subject: Re: [WiX-users] Localization filename change > > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Localization filename change
Hi Neil, We use at least two builds of WiX at the same time. Newer builds on the development computers and older and well-tested on the production server. And we upgrade the server only when we need to use some new functions. Before each upgrade we have to make sure that all our setups are not broken. For our environment, the output into subdirectories is better than culture suffix but this still is not as flexible as It could be. Is it possible to replace the proposed $(TargetDir)\CultureName\$(TargetName)$(TargetExt). with $(TargetDir)\$(CultureSuffix)\$(TargetName)$(TargetExt) where CultureSuffix is overridable and is empty by default when single culture is used? Or, even better, put $(TargetDir)\$(CultureSuffix)\$(TargetName)$(TargetExt) into the overridable property, say TargetDirLocalized. Best regards, Ilya Slobodin - Original Message - From: "Neil Enns" <[EMAIL PROTECTED]> To: "General discussion for Windows Installer XML toolset." Sent: Monday, July 21, 2008 6:18 PM Subject: Re: [WiX-users] Localization filename change > Ilya, > > If we changed things so the localized output went into > subdirectories, rather than modified the name of the MSI, would htat > work for your situation? > Neil > > > From: [EMAIL PROTECTED] > [EMAIL PROTECTED] On Behalf Of Ilya Slobodin > [EMAIL PROTECTED] > Sent: Monday, July 21, 2008 1:59 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Localization filename change - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Localization filename change
Hi Bob, Rob, Neil and others, Sorry for being so emotional, I really appreciate your work for the WiX project. >From my point of view the best approach is overridability, and backward compatibility when possible. So, I fully agree with Dominik's position. Our projects have multiple languages that are build into different subdirectories by custom scripts. That's why I was pleased to see the new multi-language-build feature and then I was slightly dissapointed that I cannot override the output name and fit into my existing environment. Anyway, such minor inconsitencies are usual for a growing project. Best regards, Ilya Slobodin - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Localization filename change
Hi list, Please vote that this issue should be resolved. I guess many WiX users have scripts that are now broken by 3.0.4309.0. I have already opened a bug on sourceforge on this issue. https://sourceforge.net/tracker/?func=detail&atid=642714&aid=2020595&group_id=105970 The bug was closed with the following reason: Bob Arnson: That was an intentional change to support building multiple localized outputs from a single project. Best regards, Ilya Slobodin - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] SqlScript, XmlFile, Pyro and patching
Colin Law wrote: > This fails giving the following error in the log. > > Action start 11:04:08: InstallSqlData. > InstallSqlData: Error 0x80070006: failed to get size of stream > InstallSqlData: Error 0x80070006: failed to read SqlScripts table Try using pyro's -notidy argument. Very helpful to see what tables are included in the patch and what are not. Best regards, Ilya Slobodin - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch install: MoveFiles and component action states
> I'd guess it's a timing problem: MSI decides what it needs to do > based > on the state of the machine during script generation. It sees > sampledb.txt on the machine in the right place with the expected > content/timestamp and says "nothing to do." You then move it but MSI > has > already made its decision about what to do. I think that the correct behavior is not to move the file here if there is "nothing to do". That's why the MoveFile table has reference to Component table. But now it is not so important. I have found the correct solution. --- You wrote in one of the previous posts that minor upgrades, whether in .msi or .msp forms, require REINSTALL & REINSTALLMODE. Same arguments in MSDN article about MsiApplyPatch function. Sample MSDN bootstrapper also has the same default command line. But my experiments with msp files show the contrary. My patch is installed properly with the simple command line msiexec /update Patch\Patch.msp /passive I thought that this line can only be used if the installer has no UI. But I added the default WixUI_InstallDir to my sample and the file was patched as expected. Next, I found the difference between my real installer and the sample one. There was a bad CA that failed without REINSTALL & REINSTALLMODE. Now the real patch is applied to the real product as expected. So, my conclusion is (I have checked v3.1 and 4.5.): When /update argument is used, that is a patch is being installed, REINSTALL & REINSTALLMODE must not be set. If set, action states of all components are set to "Local" but no real action on these components is taken. But, MoveFile records that reference such components are executed. Best regards, Ilya Slobodin - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch install: MoveFiles and component action states
> What does a verbose log say for the action state of that component?
Attached two grepped logs with different arguments, with and without
REINSTALL=ALL REINSTALLMODE=omus
1. msiexec /update Patch\Patch.msp /lv* Logs\PatchGood.log
File Sample.txt is patched
File SampleDb.txt is not touched (as expected)
2. msiexec /update Patch\Patch.msp REINSTALL=ALL REINSTALLMODE=omus /lv*
Logs\PatchBad.log
File Sample.txt is patched
SampleDb.txt is renamed to SampleDb.bak while the original file SampleDb.txt is
not reinstalled (confusing)
Best regards,
Ilya Slobodin
msiexec /update Patch\Patch.msp /lv* Logs\PatchGood.log
MSI (s) (60:00) [22:00:45:077]: File = Sample.txt: Final State = Install
MSI (s) (60:00) [22:00:45:155]: Feature: SampleDbFeature; Installed: Local;
Request: Null; Action: Null
MSI (s) (60:00) [22:00:45:155]: Component: Sample.txt; Installed: Local;
Request: Local; Action: Local
MSI (s) (60:00) [22:00:45:155]: Component: SampleDb.txt; Installed: Local;
Request: Null; Action: Null
MSI (s) (60:00) [22:00:45:155]: Component: SampleDbBackup; Installed: Local;
Request: Null; Action: Null
MSI (s) (60:00) [22:00:45:155]: Component: __Sample.txt65; Installed: Null;
Request: Local; Action: Local
MSI (s) (60:00) [22:00:45:311]: File = Sample.txt: Final State = Install
MSI (s) (60:00) [22:00:45:311]: Caching Sample.txt from C:\Program Files\Patch
Sample Directory\Sample.txt for baseline 0
MSI (s) (60:00) [22:00:45:389]: Executing op:
ComponentRegister(ComponentId={C28843DA-EF08-41CC-BA75-D2B99D8A1983},KeyPath=C:\Program
Files\Patch Sample
Directory\Sample.txt,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=0)
MSI (s) (60:00) [22:00:45:389]: Executing op:
CacheBaselineFile(Baseline=0,FileKey=Sample.txt,FilePath=C:\Program Files\Patch
Sample Directory\Sample.txt,,Existing=1)
MSI (s) (60:00) [22:00:45:389]: Note: 1: 2318 2:
C:\WINDOWS\Installer\$PatchCache$\UnManaged\S-1-5-21-448539723-1078145449-725345543-1130\9A6D3F852B508FC4EBFA8B835EA1B69B\1.0.0\Sample.txt
MSI (s) (60:00) [22:00:45:389]: Executing op:
FileCopy(SourceName=Sample.txt,SourceCabKey=Sample.txt,DestName=Sample.txt,Attributes=20480,FileSize=5,PerTick=32768,,VerifyMedia=1,CheckCRC=0,,,InstallMode=58982400,HashOptions=0,HashPart1=2101918640,HashPart2=-1436482531,HashPart3=1114628020,HashPart4=-177151165,,)
MSI (s) (60:00) [22:00:45:389]: File: C:\Program Files\Patch Sample
Directory\Sample.txt; Overwrite; Won't patch; Existing file is unversioned and
unmodified - hash doesn't match source file
MSI (s) (60:00) [22:00:45:389]: Source for file 'Sample.txt' is compressed
MSI (s) (60:00) [22:00:45:389]: Verifying accessibility of file: Sample.txt
MSI (s) (60:00) [22:00:45:436]: Note: 1: 2318 2: C:\Program Files\Patch Sample
Directory\Sample.txt
msiexec /update Patch\Patch.msp REINSTALL=ALL REINSTALLMODE=omus /lv*
Logs\PatchBad.log
MSI (c) (C0:70) [21:48:43:121]: Switching to server: TARGETDIR="d:\"
PATCH="d:\Tests\Installs\WiX\PatchTest\Patch\Patch.msp" CLIENTPROCESSID="1472"
MSPSRCED16B30AA968489D86936DC050C91242="n:\TEMP\244b46b6.msp"
CURRENTDIRECTORY="d:\Tests\Installs\WiX\PatchTest" PRODUCTLANGUAGE="1033"
CLIENTUILEVEL="0" REINSTALLMODE="omus"
_ED16B30AA968489D86936DC050C91242="d:\Tests\Installs\WiX\PatchTest\Patch\Patch.msp"
USERNAME="Ilya Slobodin" COMPANYNAME="Consistent Software" ROOTDRIVE="d:\"
EXECUTEACTION="INSTALL" ACTION="INSTALL" INSTALLLEVEL="1" SECONDSEQUENCE="1"
REINSTALL=SampleDbFeature,SampleProductFeature
MSI (s) (AC:1C) [21:48:43:152]: File = Sample.txt: Final State = Install
MSI (s) (AC:1C) [21:48:43:152]: Command Line: TARGETDIR=d:\
PATCH=d:\Tests\Installs\WiX\PatchTest\Patch\Patch.msp CLIENTPROCESSID=1472
MSPSRCED16B30AA968489D86936DC050C91242=n:\TEMP\244b46b6.msp
CURRENTDIRECTORY=d:\Tests\Installs\WiX\PatchTest PRODUCTLANGUAGE=1033
CLIENTUILEVEL=0 REINSTALLMODE=omus
_ED16B30AA968489D86936DC050C91242=d:\Tests\Installs\WiX\PatchTest\Patch\Patch.msp
USERNAME=Ilya Slobodin COMPANYNAME=Consistent Software ROOTDRIVE=d:\
EXECUTEACTION=INSTALL ACTION=INSTALL INSTALLLEVEL=1 SECONDSEQUENCE=1
REINSTALL=SampleDbFeature,SampleProductFeature ACTION=INSTALL
MSI (s) (AC:1C) [21:48:43:168]: PROPERTY CHANGE: Adding REINSTALL property. Its
value is 'SampleDbFeature,SampleProductFeature'.
MSI (s) (AC:1C) [21:48:43:246]: Feature: SampleDbFeature; Installed: Local;
Request: Reinstall; Action: Reinstall
MSI (s) (AC:1C) [21:48:43:246]: Component: Sample.txt; Installed: Local;
Request: Local; Action: Local
MSI (s) (AC:1C) [21:48:43:246]: Component: SampleDb.txt; Installed: Local;
Request: Local; Action: Local
MSI (
Re: [WiX-users] Patch install: MoveFiles and component action states
Hello Bob, > I'd suggest creating a separate component for the backup > and give it a condition of NOT PATCH. Thanks for the solution. I added a new component witn CopyFile and made it transitive. Now everything works as expected. But, this solution looks like a workaround. Most likely this is not WiX but Windows Installer issue. Is this planned behavior or not? > It's not reinstalled because you're not patching it. That is correct. And I expect that since MoveFile record references the component, and the component is not reinstalled, MoveFile record would also not be executed. But it IS executed if required arguments REINSTALL=ALL, REINSTALLMODE=omus are set. Best regards, Ilya Slobodin - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch install: MoveFiles and component action states
Bob, Yes, I understand that I need the right arguments set from either bootstrapper or command line. But, the question is what are these right arguments. I need to: 1. Get the patch installed and 2. Keep the database file and 3. Keep using the MoveFile table to backup the database I have nothing against using REINSTALL & REINSTALLMODE. But, if set, MoveFile to Component action state relationship is broken, file is moved but not reinstalled. If not set, patch is not installed. Maybe there is the third option? Possibly I cannot explain well my problem. Please compile my sample, and install patch with the following command line arguments: 1. msiexec /update Patch.msp (SampleDb.txt is neither moved nor reinstalled) 2. msiexec /update Patch.msp REINSTALL=ALL REINSTALLMODE=omus (SampleDb.txt is moved to SampleDb.bak and not reinstalled.) I expect that Component_ foreign key in the MoveFile table means that file is moved when referred component is reinstalled (the file from source is copied to the real file on disk) and not moved when file is not reinstalled. Best regards, Ilya Slobodin - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch install: MoveFiles and component action states
This makes MoveFile table completely non-functional when the file being moved is not included in the patch. In our case it's a database, much bigger than the code itself. So, the only solution is to avoid MoveFiles and write CA to suppoft custom MoveFileEx? Best regards, Ilya Slobodin - Original Message - From: "Bob Arnson" <[EMAIL PROTECTED]> To: "General discussion for Windows Installer XML toolset." Sent: Thursday, July 10, 2008 7:53 PM Subject: Re: [WiX-users] Patch install: MoveFiles and component action states > Ilya Slobodin wrote: >> Any ideas how to avoid REINSTALL & REINSTALLMODE and install the >> patch? >> > > Minor upgrades, whether in .msi or .msp forms, require those > properties. > Generally patches are delivered as wrapper .exes to execute the > patches > with the right command-line arguments. > > -- > sig://boB > http://joyofsetup.com/ > > > - > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source > project, > along with a healthy diet, reduces your potential for chronic > lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch install: MoveFiles and component action states
Sorry for the mistake in the explanation. The problem does not depend on UI, it depends only on REINSTALL & REINSTALLMODE I have to use the following command line to get my update installed: msiexec /passive /update Patch.msp REINSTALL=ALL REINSTALLMODE=omus Best regards, Ilya Slobodin - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch install: MoveFiles and component action states
Hello, I have modified the Sample Patch by Peter Marcu to test all the cases. The MoveFile problem happens only if 1. Installer has UI 2. msiexec /update Patch.msp REINSTALL=ALL REINSTALLMODE=omus is used The sample has no UI, so the simplest command line installs the update. msiexec /update Patch.msp But, if we have UI, msiexec /update Patch.msp /passive does nothing. If I add REINSTALL & REINSTALLMODE my database is gone. Any ideas how to avoid REINSTALL & REINSTALLMODE and install the patch? Best regards, Ilya Slobodin product.wxs http://schemas.microsoft.com/wix/2006/wi";> SKIP_DB patch.wxs http://schemas.microsoft.com/wix/2006/wi";> http://www.dynamocorp.com/"; DisplayName="Sample Patch" Description="Small Update Patch" Classification="Update" > make.bat if NOT EXIST 1.0 md 1.0 if NOT EXIST 1.1 md 1.1 if NOT EXIST Patch md Patch if NOT EXIST 1.0\Sample.txt echo 1.0 > 1.0\Sample.txt if NOT EXIST 1.0\SampleDb.txt echo Db-1.0 > 1.0\SampleDb.txt if NOT EXIST 1.1\Sample.txt echo 1.1 > 1.1\Sample.txt if NOT EXIST 1.1\SampleDb.txt echo Db-1.0 > 1.1\SampleDb.txt :: 1. Build Target Layout: candle.exe -dVersion=1.0 product.wxs light.exe -sval -xo Product.wixobj -out 1.0\Product.wixout light.exe 1.0\Product.wixout -out 1.0\Product.msi msiexec /a 1.0\Product.msi ROOTDRIVE=%~dp01.0\Admin :: 2. Build the Upgrade Layout: candle.exe -dVersion=1.1 product.wxs light.exe -sval -xo Product.wixobj -out 1.1\Product.wixout light.exe 1.1\Product.wixout -out 1.1\Product.msi msiexec /a 1.1\Product.msi ROOTDRIVE=%~dp01.1\Admin :: 3.a Create the wixout-based transform between your products: torch.exe -p -xi 1.0\Product.wixout 1.1\Product.wixout -out Patch\Diff.Wixmst :: 3.b Create the admin-image-based transform between your products: torch.exe -p -ax TorchBinaries -xo -t patch 1.0\Admin\Product.msi 1.1\Admin\Product.msi -out Patch\DiffAdmin.Wixmst :: 4. Build the Patches: candle.exe Patch.wxs light.exe Patch.wixobj -out Patch\Patch.WixMsp pyro.exe Patch\Patch.WixMsp -out Patch\Patch.msp -t RTM Patch\Diff.wixmst pyro.exe Patch\Patch.WixMsp -out Patch\PatchAdmin.msp -t RTM Patch\DiffAdmin.wixmst - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patch install: MoveFiles and component action states
Hello, We have a database file The database file can be modified by user, on reinstall the modified file is renamed to db.bak and original file is copied on it's place. Everything worked well until I made the patch file that modifies another file, e.g. somecode.dll. During the patch install, MoveFiles action is executed, db.dat is renamed to db.bak. But db.dat is not reinstalled as it was with reinstall. And our patched program ends up without database. ... MSI (s) (64:F8) [20:11:50:685]: Component: db.dat; Installed: Local; Request: Local; Action: Local ... MSI (s) (64:F8) [20:11:55:342]: Executing op: FileCopy(SourceName=somecode.dll,SourceCabKey=somecode.dll,DestName=somecode.dll,Attributes=20480,FileSize=2105344,PerTick=32768,,VerifyMedia=1,CheckCRC=0,Version=1.0.0.1037,Language=1033,InstallMode=58982400,,,) ... No FileCopy for db.dat ... Currently I temporarily solved the problem by modyfing with the patch MoveFiles condition to "NOT PATCH". Is there a better solution? Best regards, Ilya Slobodin - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to keep guids in similar setups
Hello List, I'm trying to build multiple similar setups (Pro, Standard, Base) of our product from a single WiX sources. And I'm trying to keep guids whenever possible. Bob Arnson wrote earlier in this list that guids are product-global and it's ok to keep the same guids, but when products are installed into different directories. Currently my investigations show most components are really product-global while some component types do not. Non-advertised shortcuts and CU registry keys are not uninstalled when another product that has the same components with the same guids is installed in different directory. E.g. we have two products, Pro and Base, both have My.exe with non-advertised shortcut pointing on it. Both exe files have the same guid and both shortcuts have the same (but different) guid. Program Files\My Product Pro\My.exe StartMenu\Programs\My Product Pro\My Product Shortcut.lnk HKCU\My Product Pro\ShortcutKeyPath Program Files\My Product Base\My.exe StartMenu\Programs\My Product Base\My Product Shortcut.lnk HKCU\My Product Base\ShortcutKeyPath 1. Install Pro into Program Files\My Product Pro 2. Install Base into Program Files\My Product Base 3. Uninstall Base (StartMenu\Programs\My Product Base\My Product Shortcut.lnk remains and it has Action: Null in the log) 4. Uninstall Pro (Pro\Shortcut to My.exe uninstalled) I use MSI 3.01 Could someone comment on this? Best regards, Ilya Slobodin - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
