[WiX-users] Burn on Windows 8
Hi all, We are using a debug build of WiX 3.6.3005 with a few changes compared to standard source files and have a problem on Windows 8 only with our bundle (managed UI). After everything is installed (or uninstalled), the chainer seems to hang for some time, and after a couple of minutes it shows an assert: "Child elevated process did not return matching exit code to parent process." (pipe.cpp / PipeTerminateChildProcess) Chainer processes end a couple of minutes later. We found out that it is somehow linked to the Windows Update service. On our Windows 8 computers the Windows Update feature is not working at the moment for machines that must pass through a proxy server. Strangely, as soon as Windows Update manages to connect (proxy bypassed) or when the Windows Update service is disabled, the chainer no longer hangs (terminates immediately). Is this a known problem (or expected one) ? Thanks, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn: Specifying PackageGroup Id on button click
Take a look at WixBA (available in the WiX source files, it's the WiX installer UI). You will find the PlanPackageBegin handler in InstallationViewModel.cs (at least for WiX version 3.6 this is true). You can set in here the state of each package from your bundle (i.e. you can always plan LaunchAction.Install, and depending on the button you use to start the install, set the state of a package to "ignore it" - e.State = RequestState.None). From: Hans ter Horst To: General discussion for Windows Installer XML toolset. Sent: Monday, October 22, 2012 12:17 PM Subject: Re: [WiX-users] Burn: Specifying PackageGroup Id on button click Thanks Rob, unfortunately I cannot find any information about the OnPackagePlan callbacks online nor can I see it used in the WixBA source code. Could you point me in the right direction? Thanks! On Fri, Oct 19, 2012 at 6:59 PM, Rob Mensching wrote: > Check on the OnPackagePlan callbacks. > > On Fri, Oct 19, 2012 at 5:19 AM, Hans ter Horst > wrote: > > > Hello, i have several simple installers that I would like group behind a > > Burn interface and start depending on the button clicked from the > > Bootstrapper interface I am designing which will have several buttons. > > For a simple bootstrapper I know > > I can use Bootstrapper.Engine.Plan(LaunchAction.Install); on hitting an > > install button and Bootstrapper.Engine.Plan(LaunchAction.Uninstall); for > > an uninstall button. How can I extend this to refer to PackageA or > PackageB > > in my Bundle.wxs file so i can differentiate between the MSI files > started? > > > > Thanks! > > -- > > http://monochrome.me.uk/blog/ > > > > > -- > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > http://p.sf.net/sfu/appdyn_sfd2d_oct > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > -- > virtually, > > Rob Mensching > http://RobMensching.com LLC > > -- > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- http://monochrome.me.uk/blog/ -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn bundle versions and BOOTSTRAPPER_ACTION_MODIFY
Just filed a bug for the BOOTSTRAPPER_ACTION_MODIFY / MajorUpgrade combination
- #3114.
Even if I misuse BOOTSTRAPPER_ACTION_MODIFY, somebody using it correctly ("as
designed") may still have this problem :).
Also rebuilding WiX/burn to write reg values in RegistrationSessionBegin on
BOOTSTRAPPER_ACTION_MODIFY also...
If somebody sees something dangerous with my particular "modify" usage or burn
code correction, please let me know... :)
____
From: Adrian Gantoi
To: General discussion for Windows Installer XML toolset.
Sent: Tuesday, October 9, 2012 12:11 PM
Subject: Re: [WiX-users] Burn bundle versions and BOOTSTRAPPER_ACTION_MODIFY
About:
"Or am I using BOOTSTRAPPER_ACTION_MODIFY incorrectly ?"
I am aware this is intended to be used to modify installed features of a MSI,
but I saw no initial problem in transforming my MSI packages into "bundle
features"...
Should I stick to planning simply BOOTSTRAPPER_ACTION_INSTALL in my bundle
"Modify" action ?
____
From: Adrian Gantoi
To: General discussion for Windows Installer XML toolset.
Sent: Tuesday, October 9, 2012 11:53 AM
Subject: [WiX-users] Burn bundle versions and BOOTSTRAPPER_ACTION_MODIFY
Hi all,
I created a bundle that can install up to 5 different MSI packages (different
products).
The bundle allows the user to install / modify / uninstall / layout through a
managed UI.
"Install" allows the user to select which MSI packages should be installed,
"Modify" which packages to be installed or uninstalled.
"Install" is available only if no defined packages is installed, "Modify"
available only if at least one package is installed (so they exclude
each-other).
I built 2 bundle versions, 1.1 and 1.2.
I have a problem with the burn behavior in a specific case, when:
- I run bundle v1.1 - install only one MSI package
- I run bundle v1.2 - add a second MSI package.
After this I will have 2 MSI packages installed and bundle v1.1 gets
uninstalled (actually only unregistered - the MSI it installed remains
installed).
Bundle v1.2 adds this new package by doing a BOOTSTRAPPER_ACTION_MODIFY.
The problem I have is that in this case the
\Windows\CurrentVersion\Uninstall\{bundle key}registry entry is not fully
configured.
It contains only "Installed" = 1 and "Resume" = 3 values.
Why this is a problem - I am trying to make a lower version bundle not execute
when a newer version bundle is already registered on a computer.
In this specific case, running again the v1.1 bundle will not detect the
related v1.2 bundle version.
I assume this happens as burn no longer finds the upgrade code entry in the
registry key.
I had a look in WiX sources (3.6.3005) - registration.cpp -
RegistrationSessionBegin writes the upgrade code only when the action is
BOOTSTRAPPER_ACTION_INSTALL or BOOTSTRAPPER_ACTION_REPAIR.
Is this a known bug/problem ? Or am I using BOOTSTRAPPER_ACTION_MODIFY
incorrectly ?
Is there a reason why RegistrationSessionBegin does not write all registry
entries also for BOOTSTRAPPER_ACTION_MODIFY ?
Question is, am I safe if I rebuild WiX after adding BOOTSTRAPPER_ACTION_MODIFY
in the RegistrationSessionBegin reg write condition check ?
Or will I face a problem (I can't figure one out now) ?
Regards,
Adrian
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn bundle versions and BOOTSTRAPPER_ACTION_MODIFY
About:
"Or am I using BOOTSTRAPPER_ACTION_MODIFY incorrectly ?"
I am aware this is intended to be used to modify installed features of a MSI,
but I saw no initial problem in transforming my MSI packages into "bundle
features"...
Should I stick to planning simply BOOTSTRAPPER_ACTION_INSTALL in my bundle
"Modify" action ?
________
From: Adrian Gantoi
To: General discussion for Windows Installer XML toolset.
Sent: Tuesday, October 9, 2012 11:53 AM
Subject: [WiX-users] Burn bundle versions and BOOTSTRAPPER_ACTION_MODIFY
Hi all,
I created a bundle that can install up to 5 different MSI packages (different
products).
The bundle allows the user to install / modify / uninstall / layout through a
managed UI.
"Install" allows the user to select which MSI packages should be installed,
"Modify" which packages to be installed or uninstalled.
"Install" is available only if no defined packages is installed, "Modify"
available only if at least one package is installed (so they exclude
each-other).
I built 2 bundle versions, 1.1 and 1.2.
I have a problem with the burn behavior in a specific case, when:
- I run bundle v1.1 - install only one MSI package
- I run bundle v1.2 - add a second MSI package.
After this I will have 2 MSI packages installed and bundle v1.1 gets
uninstalled (actually only unregistered - the MSI it installed remains
installed).
Bundle v1.2 adds this new package by doing a BOOTSTRAPPER_ACTION_MODIFY.
The problem I have is that in this case the
\Windows\CurrentVersion\Uninstall\{bundle key}registry entry is not fully
configured.
It contains only "Installed" = 1 and "Resume" = 3 values.
Why this is a problem - I am trying to make a lower version bundle not execute
when a newer version bundle is already registered on a computer.
In this specific case, running again the v1.1 bundle will not detect the
related v1.2 bundle version.
I assume this happens as burn no longer finds the upgrade code entry in the
registry key.
I had a look in WiX sources (3.6.3005) - registration.cpp -
RegistrationSessionBegin writes the upgrade code only when the action is
BOOTSTRAPPER_ACTION_INSTALL or BOOTSTRAPPER_ACTION_REPAIR.
Is this a known bug/problem ? Or am I using BOOTSTRAPPER_ACTION_MODIFY
incorrectly ?
Is there a reason why RegistrationSessionBegin does not write all registry
entries also for BOOTSTRAPPER_ACTION_MODIFY ?
Question is, am I safe if I rebuild WiX after adding BOOTSTRAPPER_ACTION_MODIFY
in the RegistrationSessionBegin reg write condition check ?
Or will I face a problem (I can't figure one out now) ?
Regards,
Adrian
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn bundle versions and BOOTSTRAPPER_ACTION_MODIFY
Hi all,
I created a bundle that can install up to 5 different MSI packages (different
products).
The bundle allows the user to install / modify / uninstall / layout through a
managed UI.
"Install" allows the user to select which MSI packages should be installed,
"Modify" which packages to be installed or uninstalled.
"Install" is available only if no defined packages is installed, "Modify"
available only if at least one package is installed (so they exclude
each-other).
I built 2 bundle versions, 1.1 and 1.2.
I have a problem with the burn behavior in a specific case, when:
- I run bundle v1.1 - install only one MSI package
- I run bundle v1.2 - add a second MSI package.
After this I will have 2 MSI packages installed and bundle v1.1 gets
uninstalled (actually only unregistered - the MSI it installed remains
installed).
Bundle v1.2 adds this new package by doing a BOOTSTRAPPER_ACTION_MODIFY.
The problem I have is that in this case the
\Windows\CurrentVersion\Uninstall\{bundle key}registry entry is not fully
configured.
It contains only "Installed" = 1 and "Resume" = 3 values.
Why this is a problem - I am trying to make a lower version bundle not execute
when a newer version bundle is already registered on a computer.
In this specific case, running again the v1.1 bundle will not detect the
related v1.2 bundle version.
I assume this happens as burn no longer finds the upgrade code entry in the
registry key.
I had a look in WiX sources (3.6.3005) - registration.cpp -
RegistrationSessionBegin writes the upgrade code only when the action is
BOOTSTRAPPER_ACTION_INSTALL or BOOTSTRAPPER_ACTION_REPAIR.
Is this a known bug/problem ? Or am I using BOOTSTRAPPER_ACTION_MODIFY
incorrectly ?
Is there a reason why RegistrationSessionBegin does not write all registry
entries also for BOOTSTRAPPER_ACTION_MODIFY ?
Question is, am I safe if I rebuild WiX after adding BOOTSTRAPPER_ACTION_MODIFY
in the RegistrationSessionBegin reg write condition check ?
Or will I face a problem (I can't figure one out now) ?
Regards,
Adrian
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn - multiple PackageGroupRef in Chain - download issues
Hi Rob, Had a look on the source code and found the reason for this behavior. In the ApplyCache function, the code calls DoRollbackCache after a download error, which uses all the BURN_CACHE_ACTION_TYPE_CHECKPOINT action types. This will remove all previously completely cached packages. The currently downloading package did not get to the point it creates this action type, so it will not get removed. This does not seem a bug, it's more of a "by design" issue. Is it possible to change this behavior for a next version/build ? For a bootstrapper which installs several large packages, removing some previously completely cached packages before they are installed is a bit of a problem. Maybe this call to DoRollbackCache can be at least moved in another function, like CoreQuit, so the user can at least get a chance to re-attempt the install on a TryAgainCommand ? Thanks, Adrian ____ From: Adrian Gantoi To: Rob Mensching ; General discussion for Windows Installer XML toolset. Sent: Monday, August 13, 2012 3:21 PM Subject: Re: [WiX-users] Burn - multiple PackageGroupRef in Chain - download issues Hi Rob, Thanks for your answer. Even if I did not yet find the reason or workaround for the packages being removed from cache on this error, I found the reason for the "Failed to resolve source for file" error. I am using a managed UI which was redesigned starting from the WiX installer managed UI, and the problem was in InstallationViewModel.ResolveSource. this.downloadRetries[e.PackageOrContainerId] = retries + 1; e.Result = retries < 3 && !String.IsNullOrEmpty(e.DownloadSource) ? Result.Download : Result.Ok; It just stopped due to this on the first package with more than 3 payloads... I will keep looking for the problem with the completely downloaded packages being removed from cache in such a case and send an email or create a bug in case I spot the problem. Thanks, Adrian ________ From: Rob Mensching To: Adrian Gantoi ; General discussion for Windows Installer XML toolset. Sent: Monday, August 13, 2012 12:06 AM Subject: Re: [WiX-users] Burn - multiple PackageGroupRef in Chain - download issues There was a bug reported that packages are incorrectly being cleaned from the cache during repair. It is possible this is the same or similar bug. A full log file would be necessary to understand better. You will get the error code on the XxxComplete() callbacks. There is also a bug open to send more error messages. However, I do not understand the root issue that is causing the original failure, triggering the clean up. That would need a more complete log file to diagnose. On Fri, Aug 10, 2012 at 8:20 AM, Adrian Gantoi wrote: Hi all, > >I have a question on using burn for a multi package install with full download. >I have a chain of packages like below: > > > > > > > > > > >Each PackageGroup consists of a MSI and it's payloads. All have the >DownloadUrl data set - I deliver only the exe which should download everything. >I did not specify anything for the Cache attribute in any of the MsiPackage >units. > >My problem is that for some reason, at some random point, for example, the >chainer stops with an error like: >Prompt for source of package: 4.msi, payload: aaa.cab, path:... >Failed to resolve source for file: aaa.cab, error: 0x80070002. >Error 0x80070002: Failed while prompting for source (original path >'aaa.cab'). >Failed to acquire payload: aaa.cab to working path: C:\DOCUME~1\aaa.cab, >error: 0x80070002. > > >This happens randomly for one of the packages (all have large size payloads). >When this happens while downloading payloads for the msi4 package (for >example), the log will show: >Removing cached package: 3.msi, from path: >Removing cached package: 2.msi, from path: >Removing cached package: 1.msi, from path: > > >I end up having after this some still cached files from the 4.msi package (all >that got downloaded), and no files remain cached from the previous packages in >the chain. >If I start the chainer again, the download will be restarted for the first 3 >packages and some files will be found when getting to 4th package. >Why do the first 3 get removed and the incompletely downloaded package remains >partially cached ? >I need to avoid the re-download of the first 3 packages due to their big size. >Can I do something that in such a case, all downloaded packages remain cached >until they are uninstalled ? >Specifying Cache="yes" on each MsiPackage will produce this result ? Does >Cache="yes" means they will remain cached until they are uninstalled (even if >they are not
Re: [WiX-users] vcredist_x86.exe Package DownloadUrl
Probably the safest place to link to is the Microsoft Download Center. Go to http://download.microsoft.com, search for (e.g.) "Visual C++ 200x" and you will get a list of results. Locate what you need in here and click on download - most of these "download" links will open a new page for the download to confirm it. Copy the real download URL from the "Start download" link in this new page. From: David L. Beckwith To: wix-users@lists.sourceforge.net Sent: Friday, August 17, 2012 7:13 PM Subject: [WiX-users] vcredist_x86.exe Package DownloadUrl I was using a DownloadUrl from Microsoft as a burn package. Today, this url no longer exists. Is there an official site Microsoft will maintain or do I need to copy this file to my server? Can I legally post it on my server? I notice some use this url: http://go.microsoft.com/fwlink/?LinkID=210621 Is this safe to use without changing? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/vcredist-x86-exe-Package-DownloadUrl-tp7579927.html Sent from the wix-users mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn - multiple PackageGroupRef in Chain - download issues
Hi Rob, Thanks for your answer. Even if I did not yet find the reason or workaround for the packages being removed from cache on this error, I found the reason for the "Failed to resolve source for file" error. I am using a managed UI which was redesigned starting from the WiX installer managed UI, and the problem was in InstallationViewModel.ResolveSource. this.downloadRetries[e.PackageOrContainerId] = retries + 1; e.Result = retries < 3 && !String.IsNullOrEmpty(e.DownloadSource) ? Result.Download : Result.Ok; It just stopped due to this on the first package with more than 3 payloads... I will keep looking for the problem with the completely downloaded packages being removed from cache in such a case and send an email or create a bug in case I spot the problem. Thanks, Adrian From: Rob Mensching To: Adrian Gantoi ; General discussion for Windows Installer XML toolset. Sent: Monday, August 13, 2012 12:06 AM Subject: Re: [WiX-users] Burn - multiple PackageGroupRef in Chain - download issues There was a bug reported that packages are incorrectly being cleaned from the cache during repair. It is possible this is the same or similar bug. A full log file would be necessary to understand better. You will get the error code on the XxxComplete() callbacks. There is also a bug open to send more error messages. However, I do not understand the root issue that is causing the original failure, triggering the clean up. That would need a more complete log file to diagnose. On Fri, Aug 10, 2012 at 8:20 AM, Adrian Gantoi wrote: Hi all, > >I have a question on using burn for a multi package install with full download. >I have a chain of packages like below: > > > > > > > > > > >Each PackageGroup consists of a MSI and it's payloads. All have the >DownloadUrl data set - I deliver only the exe which should download everything. >I did not specify anything for the Cache attribute in any of the MsiPackage >units. > >My problem is that for some reason, at some random point, for example, the >chainer stops with an error like: >Prompt for source of package: 4.msi, payload: aaa.cab, path:... >Failed to resolve source for file: aaa.cab, error: 0x80070002. >Error 0x80070002: Failed while prompting for source (original path >'aaa.cab'). >Failed to acquire payload: aaa.cab to working path: C:\DOCUME~1\aaa.cab, >error: 0x80070002. > > >This happens randomly for one of the packages (all have large size payloads). >When this happens while downloading payloads for the msi4 package (for >example), the log will show: >Removing cached package: 3.msi, from path: >Removing cached package: 2.msi, from path: >Removing cached package: 1.msi, from path: > > >I end up having after this some still cached files from the 4.msi package (all >that got downloaded), and no files remain cached from the previous packages in >the chain. >If I start the chainer again, the download will be restarted for the first 3 >packages and some files will be found when getting to 4th package. >Why do the first 3 get removed and the incompletely downloaded package remains >partially cached ? >I need to avoid the re-download of the first 3 packages due to their big size. >Can I do something that in such a case, all downloaded packages remain cached >until they are uninstalled ? >Specifying Cache="yes" on each MsiPackage will produce this result ? Does >Cache="yes" means they will remain cached until they are uninstalled (even if >they are not installed, just cached after download) ? > > >A second question - is there any event raised/property changed in such a case >(failed download) - just to be able to inform the user about the error ? > >Regards, >Adrian >-- >Live Security Virtual Conference >Exclusive live event will cover all the ways today's security and >threat landscape has changed and how IT managers can respond. Discussions >will include endpoint security, mobile security and the latest in malware >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >___ >WiX-users mailing list >WiX-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/wix-users > -- virtually, Rob Mensching http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn - multiple PackageGroupRef in Chain - download issues
Hi all, I have a question on using burn for a multi package install with full download. I have a chain of packages like below: Each PackageGroup consists of a MSI and it's payloads. All have the DownloadUrl data set - I deliver only the exe which should download everything. I did not specify anything for the Cache attribute in any of the MsiPackage units. My problem is that for some reason, at some random point, for example, the chainer stops with an error like: Prompt for source of package: 4.msi, payload: aaa.cab, path:... Failed to resolve source for file: aaa.cab, error: 0x80070002. Error 0x80070002: Failed while prompting for source (original path 'aaa.cab'). Failed to acquire payload: aaa.cab to working path: C:\DOCUME~1\aaa.cab, error: 0x80070002. This happens randomly for one of the packages (all have large size payloads). When this happens while downloading payloads for the msi4 package (for example), the log will show: Removing cached package: 3.msi, from path: Removing cached package: 2.msi, from path: Removing cached package: 1.msi, from path: I end up having after this some still cached files from the 4.msi package (all that got downloaded), and no files remain cached from the previous packages in the chain. If I start the chainer again, the download will be restarted for the first 3 packages and some files will be found when getting to 4th package. Why do the first 3 get removed and the incompletely downloaded package remains partially cached ? I need to avoid the re-download of the first 3 packages due to their big size. Can I do something that in such a case, all downloaded packages remain cached until they are uninstalled ? Specifying Cache="yes" on each MsiPackage will produce this result ? Does Cache="yes" means they will remain cached until they are uninstalled (even if they are not installed, just cached after download) ? A second question - is there any event raised/property changed in such a case (failed download) - just to be able to inform the user about the error ? Regards, Adrian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn - installing .NET Framework 3.5 on Windows XP SP2
Hi all,
I have a problem which I cannot figure out - I created a bundle using WiX 3.6
(build 2803).
The UI is a WPF component so I had to request the install of .NET Framework 3.5
for this (UI modified from WiX installer UI - WixBA - changed target framework
to 3.5).
The bundle fails to install the framework and I can't find figure which is the
reason for this.
Can you give me some ideas about what could be wrong ?
I am trying to install it on a virtual machine which runs Windows XP
Professional SP2. On some machines with Win7 the bundle installs correctly (but
here the 3.5 framework is already installed).
dotnetfx35.exe included in the build is the full setup for the framework (not
the bootstrapper).
Also, as I side problem for this - the .NET Framework 3.5 setup requires at
least Windows Installer 3.1, which is not installed with XP SP2.
I manually installed Windows Installer 4.5 before attempting to install the
bundle with the framework.
How can I solve this for a final bundle (how can I install Windows Installer
4.5, then .NET Framework 3.5 so the UI gets a chance to run ?).
Code in the bundle and UI stuff as below.
Bundle:
http://download.microsoft.com/download/6/0/f/60fc5854-3cb8-4892-b6db-bd4f42510f28/dotnetfx35.exe";
InstallCommand="/q /norestart /lang:ENU"
RepairCommand="/q /norestart /lang:ENU"
UninstallCommand="/q /norestart /lang:ENU"
InstallCondition="NOT Netfx35Version"
DetectCondition="Netfx35Version">
WixBA.BootstrapperCore.config:
Please let me know if you need some other data about this...
See below the bundle log entries which have something to do with my problem:
I don't see any attempt to install the framework in the log file...
Thanks for any hints.
[04C0:0208][2012-07-16T16:53:16]: Burn v3.6.2803.0, Windows v5.1 (Build 2600:
Service Pack 2), path: \\...\Public\chainer\Setup.exe, cmdline: ''
...
[04C0:0208][2012-07-16T16:53:16]: Loading prerequisite bootstrapper application
because managed host could not be loaded, error: 0x80070490.
[04C0:0208][2012-07-16T16:53:16]: Detect 1 packages
...
[04C0:0208][2012-07-16T16:53:16]: Registry key not found. Key =
'SOFTWARE\Microsoft\Net Framework Setup\NDP\v3.5'
[04C0:0208][2012-07-16T16:53:16]: Setting numeric variable 'Netfx35Version' to
value 0
...
[04C0:0208][2012-07-16T16:53:16]: Condition 'Netfx35Version' evaluates to false.
[04C0:0208][2012-07-16T16:53:16]: Detected package: dotnetfx35.exe, state:
Absent, cached: None
[04C0:0208][2012-07-16T16:53:16]: Detect complete, result: 0x0
[04C0:0208][2012-07-16T16:53:17]: Plan 1 packages, action: Install
[04C0:0208][2012-07-16T16:53:17]: Condition 'NOT Netfx35Version' evaluates to
true.
[04C0:0208][2012-07-16T16:53:17]: Skipping dependency registration on package
with no dependency providers: dotnetfx35.exe
[04C0:0208][2012-07-16T16:53:17]: Planned package: dotnetfx35.exe, state:
Absent, default requested: Present, ba requested: None, execute: None,
rollback: None, cache: No, uncache: No, dependency: None
[04C0:0208][2012-07-16T16:53:17]: Plan complete, result: 0x0
[04C0:0208][2012-07-16T16:53:17]: Apply begin
[04CC:06B4][2012-07-16T16:53:19]: Creating a system restore point.
[04CC:06B4][2012-07-16T16:53:20]: Created a system restore point.
[04CC:06B4][2012-07-16T16:53:20]: Caching bundle from:
'C:\DOCUME~1\...\LOCALS~1\Temp\{72599d17-5f3a-48ec-9fab-cac29802a4d2}\.be\Setup.exe'
to: 'C:\Documents and Settings\All Users\Application Data\Package
Cache\{72599d17-5f3a-48ec-9fab-cac29802a4d2}\Setup.exe'
[04CC:06B4][2012-07-16T16:53:22]: Registering bundle dependency provider:
{72599d17-5f3a-48ec-9fab-cac29802a4d2}, version: 1.0.0.0
[04C0:0208][2012-07-16T16:53:23]: Apply complete, result: 0x0, restart: None,
ba requested restart: No
[04C0:0208][2012-07-16T16:53:23]: Shutting down, exit code: 0x0
[04C0:0208][2012-07-16T16:53:23]: The prerequisites were not successfully
installed, error: 0x0. The bootstrapper application will be not reloaded.
...
[04C0:0208][2012-07-16T16:53:23]: Variable: Netfx35Version = 0
...
[04C0:0208][2012-07-16T16:53:23]: Variable: WixBundleAction = 4
[04C0:0208][2012-07-16T16:53:23]: Variable: WixBundleElevated = 1
[04C0:0208][2012-07-16T16:53:23]: Variable: WixBundleInstalled = 0
[04C0:0208][2012-07-16T16:53:23]: Variable: WixBundleLog =
C:\DOCUME~1\...\LOCALS~1\Temp\..._Bundle_20120716165316.log
[04C0:0208][2012-07-16T16:53:23]: Variable: WixBundleName = ... Bundle
[04C0:0208][2012-07-16T16:53:23]: Variable: WixBundleOriginalSource =
\\...\Public\chainer\Setup.exe
[04C0:0208][2012-07-16T16:53:23]: Variable: WixBundleProv
[WiX-users] WiX 3.5 : problem with melted MSM content
Hello, I am trying to build a setup using WiX 3.5 build (migrating from WiX 3.0). This setup includes a melt generated wxs file (from a MSM). I have a problem due to the fact that the MSM intends to grant access rights on a particular folder it creates. Due to this, in the generated wxs I have content similar to: INSTALLLOCATION CreateFolder Everyone 268435456 The setup will also grant access rights on a different folder (using Util:PermissionEx). When I build the setup, I get this error: C:\Users\zzz\AppData\Local\Temp\rfapltdr\SecureObjects.idt : error LGHT0136: There was an error importing table 'SecureObjects' from file 'C:\Users\zzz\AppData\Local\Temp\rfapltdr\SecureObjects.idt' Any hints on what is wrong ? I failed to find a reason for this error. Thanks, Adrian -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Product uninstall problem when removing first a patch
Hi Bob, I am unable to find any change that would imply a removed component (no components were removed, no GUIDs changed). The only thing I can think of is maybe the transform for the only MSI adding a font installation could produce problems (even if it's not the applied transform), as the patch is a single patch for all MSIs. Any other reasons you can think of for such problems ? I would like to avoid having to mark the patch as "not uninstallable" I am not very sure what you meant by: "You need to check the feature states after each operation, not just during" Thanks, Adrian From: Bob Arnson To: General discussion for Windows Installer XML toolset. Sent: Tue, November 10, 2009 3:13:04 PM Subject: Re: [WiX-users] Product uninstall problem when removing first a patch Adrian Gantoi wrote: > I also had a look on reported feature states at each step (I'll report below > my major features' states). > Results: > - product install - no comments > - SP2 install - no errors reported - features : Installed=Local, > Request=Reinstall, Action=Reinstall > - SP2 uninstall - no errors reported - features : Installed=Local, > Request=Reinstall, Action=Reinstall > - product uninstall - no errors reported - features : Installed=Advertise, > Request=Absent, Action=Absent > > I don't understand the features' "Advertise" state . > The most common cause is minor upgrades that remove components. You need to check the feature states after each operation, not just during. See also http://blogs.msdn.com/heaths/archive/2009/01/27/repairing-products-after-patches-advertised-features.aspx. -- sig://boB http://joyofsetup.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] Product uninstall problem when removing first a patch
Bob Arnson wrote: > Search the log for SELMGR. The log files do not contain it... From: Adrian Gantoi To: General discussion for Windows Installer XML toolset. Sent: Mon, November 9, 2009 5:14:48 PM Subject: Re: [WiX-users] Product uninstall problem when removing first a patch Hi all, OK, re-run the installation for the faulty case (build 1.1 + SP2 patch) with logging all the way... The installation was successful, even with MSIENFORCEUPGRADECOMPONENTRULES=1. I looked at the log files with the help of Windows Installer Verbose Log Analyzer tool, and none of the 4 logs reported any errors (read "tool did not report errors"). I also had a look on reported feature states at each step (I'll report below my major features' states). Results: - product install - no comments - SP2 install - no errors reported - features : Installed=Local, Request=Reinstall, Action=Reinstall - SP2 uninstall - no errors reported - features : Installed=Local, Request=Reinstall, Action=Reinstall - product uninstall - no errors reported - features : Installed=Advertise, Request=Absent, Action=Absent I don't understand the features' "Advertise" state . Any other hints for my problem? I don't think component rules were broken. There are only 2 MSI files (same language, Win32 and x64 versions) which I know could have this problem (due to font installation), but I have not tested with them, I used a "safe" MSI, and the patch doesn't reference the font component... Regards, Adrian From: Blair To: General discussion for Windows Installer XML toolset. Sent: Mon, November 9, 2009 3:52:26 PM Subject: Re: [WiX-users] Product uninstall problem when removing first a patch Perchance did you remove any components in your SP2 patch? Set MSIENFORCEUPGRADECOMPONENTRULES=1 in both commandlines when rerunning the scenario. If you get an installation failure that should point you to at least one component rule violation that will produce the effect you are describing. -Original Message- From: Adrian Gantoi [mailto:gantoiadr...@yahoo.com] Sent: Monday, November 09, 2009 4:29 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Product uninstall problem when removing first a patch Hi all, I have the following problem with our installer for which we deliver a service pack (patch) setup. We use for the setup and patch build the WiX build 3.0.4014.0. Situation is as follows: a) we built (and shipped) our product MSI (let's call it build 1.0). b) we built (and shipped) a full new MSI for our product, which includes the Service Pack 1 updates (let's call this build 1.1). and also a patch setup Service Pack 1 (for customers having build 1.0). Now we need to build and ship a Service Pack 2 patch, which should update both a) and b) MSIs. The patches are built using torch/pyro. The "baseline" build used for patch build is build a) (build 1.0). The problem: - install build 1.1 - install patch (SP2) - uninstall patch - uninstall product leaves behind all files Removing the product completely (after patch install) deletes all files, problem appears only if patch is first uninstalled. Any hints for me about what could be wrong (an why...)? I made two logged uninstalls, and the components seem to be not linked to the product in the faulty scenario: MSI (s) (EC:50) [11:56:01:609]: Executing op: ActionStart(Name=ProcessComponents,Description=Updating component registration,) MSI (s) (EC:50) [11:56:01:609]: Executing op: ProgressTotal(Total=1,Type=1,ByteEquivalent=24000) When directly uninstalling the whole product, the log contains: MSI (s) (C8:A8) [14:02:14:875]: Executing op: ActionStart(Name=ProcessComponents,Description=Updating component registration,) MSI (s) (C8:A8) [14:02:14:875]: Executing op: ProgressTotal(Total=1218,Type=1,ByteEquivalent=24000) I should mention also: - build 1.0 and build 1.1 actually mean a bunch of MSIs (different ProductCode, same UpgradeCode), as we deliver one MSI for each language (15) and each platform (2). - we have a single patch for all / not possible to install two MSIs at the same time. - the MSIs for build 1.1 are "more" than build 1.0 + Service Pack 1 patch. Build 1.1 MSIs contain in addition a font installation (for only one language) and several other added or updated (files binary different) components not included in the Service Pack 1 patch. Thanks, Adrian -- 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 m
Re: [WiX-users] Product uninstall problem when removing first a patch
Hi all, OK, re-run the installation for the faulty case (build 1.1 + SP2 patch) with logging all the way... The installation was successful, even with MSIENFORCEUPGRADECOMPONENTRULES=1. I looked at the log files with the help of Windows Installer Verbose Log Analyzer tool, and none of the 4 logs reported any errors (read "tool did not report errors"). I also had a look on reported feature states at each step (I'll report below my major features' states). Results: - product install - no comments - SP2 install - no errors reported - features : Installed=Local, Request=Reinstall, Action=Reinstall - SP2 uninstall - no errors reported - features : Installed=Local, Request=Reinstall, Action=Reinstall - product uninstall - no errors reported - features : Installed=Advertise, Request=Absent, Action=Absent I don't understand the features' "Advertise" state . Any other hints for my problem? I don't think component rules were broken. There are only 2 MSI files (same language, Win32 and x64 versions) which I know could have this problem (due to font installation), but I have not tested with them, I used a "safe" MSI, and the patch doesn't reference the font component... Regards, Adrian From: Blair To: General discussion for Windows Installer XML toolset. Sent: Mon, November 9, 2009 3:52:26 PM Subject: Re: [WiX-users] Product uninstall problem when removing first a patch Perchance did you remove any components in your SP2 patch? Set MSIENFORCEUPGRADECOMPONENTRULES=1 in both commandlines when rerunning the scenario. If you get an installation failure that should point you to at least one component rule violation that will produce the effect you are describing. -Original Message- From: Adrian Gantoi [mailto:gantoiadr...@yahoo.com] Sent: Monday, November 09, 2009 4:29 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Product uninstall problem when removing first a patch Hi all, I have the following problem with our installer for which we deliver a service pack (patch) setup. We use for the setup and patch build the WiX build 3.0.4014.0. Situation is as follows: a) we built (and shipped) our product MSI (let's call it build 1.0). b) we built (and shipped) a full new MSI for our product, which includes the Service Pack 1 updates (let's call this build 1.1). and also a patch setup Service Pack 1 (for customers having build 1.0). Now we need to build and ship a Service Pack 2 patch, which should update both a) and b) MSIs. The patches are built using torch/pyro. The "baseline" build used for patch build is build a) (build 1.0). The problem: - install build 1.1 - install patch (SP2) - uninstall patch - uninstall product leaves behind all files Removing the product completely (after patch install) deletes all files, problem appears only if patch is first uninstalled. Any hints for me about what could be wrong (an why...)? I made two logged uninstalls, and the components seem to be not linked to the product in the faulty scenario: MSI (s) (EC:50) [11:56:01:609]: Executing op: ActionStart(Name=ProcessComponents,Description=Updating component registration,) MSI (s) (EC:50) [11:56:01:609]: Executing op: ProgressTotal(Total=1,Type=1,ByteEquivalent=24000) When directly uninstalling the whole product, the log contains: MSI (s) (C8:A8) [14:02:14:875]: Executing op: ActionStart(Name=ProcessComponents,Description=Updating component registration,) MSI (s) (C8:A8) [14:02:14:875]: Executing op: ProgressTotal(Total=1218,Type=1,ByteEquivalent=24000) I should mention also: - build 1.0 and build 1.1 actually mean a bunch of MSIs (different ProductCode, same UpgradeCode), as we deliver one MSI for each language (15) and each platform (2). - we have a single patch for all / not possible to install two MSIs at the same time. - the MSIs for build 1.1 are "more" than build 1.0 + Service Pack 1 patch. Build 1.1 MSIs contain in addition a font installation (for only one language) and several other added or updated (files binary different) components not included in the Service Pack 1 patch. Thanks, Adrian -- 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, c
[WiX-users] Product uninstall problem when removing first a patch
Hi all, I have the following problem with our installer for which we deliver a service pack (patch) setup. We use for the setup and patch build the WiX build 3.0.4014.0. Situation is as follows: a) we built (and shipped) our product MSI (let's call it build 1.0). b) we built (and shipped) a full new MSI for our product, which includes the Service Pack 1 updates (let's call this build 1.1). and also a patch setup Service Pack 1 (for customers having build 1.0). Now we need to build and ship a Service Pack 2 patch, which should update both a) and b) MSIs. The patches are built using torch/pyro. The "baseline" build used for patch build is build a) (build 1.0). The problem: - install build 1.1 - install patch (SP2) - uninstall patch - uninstall product leaves behind all files Removing the product completely (after patch install) deletes all files, problem appears only if patch is first uninstalled. Any hints for me about what could be wrong (an why...)? I made two logged uninstalls, and the components seem to be not linked to the product in the faulty scenario: MSI (s) (EC:50) [11:56:01:609]: Executing op: ActionStart(Name=ProcessComponents,Description=Updating component registration,) MSI (s) (EC:50) [11:56:01:609]: Executing op: ProgressTotal(Total=1,Type=1,ByteEquivalent=24000) When directly uninstalling the whole product, the log contains: MSI (s) (C8:A8) [14:02:14:875]: Executing op: ActionStart(Name=ProcessComponents,Description=Updating component registration,) MSI (s) (C8:A8) [14:02:14:875]: Executing op: ProgressTotal(Total=1218,Type=1,ByteEquivalent=24000) I should mention also: - build 1.0 and build 1.1 actually mean a bunch of MSIs (different ProductCode, same UpgradeCode), as we deliver one MSI for each language (15) and each platform (2). - we have a single patch for all / not possible to install two MSIs at the same time. - the MSIs for build 1.1 are "more" than build 1.0 + Service Pack 1 patch. Build 1.1 MSIs contain in addition a font installation (for only one language) and several other added or updated (files binary different) components not included in the Service Pack 1 patch. Thanks, Adrian -- 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] Uninstall Problem if installed on non system partition
Hi,
I am not sure if your problem comes from this, but I experienced in the past a
similar problem with yours.
Windows Installer did not correctly resolve the real location of a folder in a
Repair/Uninstall scenario.
This happened to me for folders which did not have any files installed inside
(only other folders).
MSI seems to resolve the folder path based on components referencing the folder.
I managed to have the proper values after defining some components with the
folders as KeyPath, like below:
Hope this helps.
Adrian.
From: Tom Kazimiers <2voo...@gmx.de>
To: General discussion for Windows Installer XML toolset.
Sent: Wednesday, July 29, 2009 5:17:19 PM
Subject: Re: [WiX-users] Uninstall Problem if installed on non system partition
Hi,
thans for the hint, with the verbose logging (I guess "/lvx!
install.log" for msiexec will do it?). The files get installed in the
correct directory (namely that one the user chooses in the install
settings dialog). The variable saving this location is named
INSTALLLOCATION. I use it in the following structure:
...content of my folder...
And I set the the following WiX variable:
I tryed that one with INSTALLLOCATION, too, but it did not change anything.
Well, the install log says the following about INSTALLLOCATION:
...
MSI (c) (E0:88) [15:54:53:011]: PROPERTY CHANGE: Adding INSTALLLOCATION
property. Its value is 'C:\Program Files\MyAppName\'.
...
MSI (s) (FC:78) [16:09:16:756]: Dir (target): Key: TARGETDIR,
Object: E:\
...
MSI (c) (E0:88) [15:54:53:081]: Dir (target): Key: INSTALLLOCATION,
Object: C:\Program Files\MyAppName\
...
MSI (c) (E0:88) [15:54:58:730]: PROPERTY CHANGE: Adding _BrowseProperty
property. Its value is 'INSTALLLOCATION'.
...
MSI (c) (E0:88) [15:55:01:383]: PROPERTY CHANGE: Modifying
INSTALLLOCATION property. Its current value is 'C:\Program
Files\MyAppName\'. Its new value: 'E:\Program Files\MyAppName\'.
...
MSI (c) (E0:88) [15:55:03:186]: Switching to server: ...
INSTALLLOCATION="E:\Program Files\MyAppName\" TARGETDIR="E:\" ...
ROOTDRIVE="E:\"
...
[and some more locations, but erverywhere it is like it should be]
Now, if I uninstall with the same MSI the GUI works without any problem
(beside that somehow a small font is set) and the following occurences
are in the log:
...
MSI (s) (FC:78) [16:09:16:709]: PROPERTY CHANGE: Adding INSTALLLOCATION
property. Its value is 'C:\Program Files\MyAppName\'.
...
MSI (s) (FC:78) [16:09:16:779]: Dir (target): Key: INSTALLLOCATION,
Object: C:\Program Files\MyAppName\
...
MSI (s) (FC:78) [16:09:19:069]: Executing op:
SetTargetFolder(Folder=C:\Program Files\MyAppName\)
MSI (s) (FC:78) [16:09:19:079]: Executing op:
FileRemove(,FileName=MyAppName.exe,,ComponentId={07F89156-0254-4C41-AC90-282090205D32})
...
MSI (s) (FC:78) [16:09:18:506]: Executing op:
RegRemoveValue(,Value=[INSTALLLOCATION]MyAppName.exe,0,)
Clearly, the FileRemove can not work out since INSTALLLOCATION is set to
the wrong value. But how comes that there is not the right value in it?
Have I to tell MSI that to save it?
One solution would be to save the INSTALLLOCATION in the registry (in
fact, I to this already) and read it in on uninstall and replace
INSTALLLOCATION. But I would not like to do this, since this value could
be changed and get missed (or sth.) - It would be gread if you Chris, or
someone else, has a hint for me.
Thanks ain advance,
Tom
Chris Lord wrote:
> Tom,
>
> I do not know. I have never had any problems with the cache but then
> again the installers I have built aren't exactly complicated!
>
> However, first place I would look is to run an install on a fresh
> machine with verbose logging and see if the files are being installed to
> the directory you expect.
>
> Chris
>
>
> -Original Message-
> From: Tom Kazimiers [mailto:2voo...@gmx.de]
> Sent: Monday, July 27, 2009 17:11
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Uninstall Problem if installed on non system
> partition
>
> Chris,
>
> thanks for the hint with the MSI log. I looked into it and found
> something odd:
> The INSTALLLOCATION-Directory property has another value then where the
> application is installed. This is strange since it is declared as the
> base directory in the setup sources and not modified anywhere else.
>
> Coulds this have something to do with MSI caching?
>
> Thanks,
> Tom
>
> Chris Lord wrote:
>
>> Tom
>>
>> For files your installer places on the hard disk, the uninstall should
>>
>
>
>> remove them automatically unless they are still in use. There should
>> be no need for you to manually remove these files. Directories are a
>> different matter as the uninstall will not remove it if the directory
>> is not empty. This typically happens if the application generates its
>>
>
>
>> own files when running. The uninstall
Re: [WiX-users] Single patch for multiple products
Hi Heath, To better clarify my problem and the (maybe) strange components architecture of the setup, I will give a better detailed explanation. We have a setup for a product which can be installed in different languages. English and French for example. We created different build configuration for the setup (one configuration for English and one for French). The result of the setup build consists in two products (different product GUID). So, we have two products, which include a set of common, language independent files (identical components, in every aspect), and a set of different, language dependent files (components which have the same Id, different GUID, and which install different (as contents) files in the same location). In other words, a file "c:\dir\file.sss" exists after either installation, but it's coming from a different component (different GUID) and it has a different content, depending on the language of the installed product. The two products cannot be installed in the same time (so only one is installed at some point), so we do not have the problem with the files being uninstalled incorrectly. My problem is simply linked to the patch. Apparently we cannot patch the "c:\dir\file.sss" file with a single MSP for both products. Somehow, the wrong transform is applied (the transform for product 2 when product 1 is installed) I have to admit that until now I did not debug WiX tools to see if the problem comes from WiX, or if it's linked to the fact that the different components have the same Id, since until now we did not have to patch any of the language dependent files. At this point, my problem is only a technical issue, and I am trying to see what's wrong, to avoid doing the same mistake for the next release of the product, or if it's a limitation of MSI or WiX problem. Basically, I must find out if in MSI world is "possible" to install different files, but with the same name and install location, from different products (which cannot be installed at the same time), which can be patched afterwards with a single MSP. Thanks, Adrian Heath Stewart <[EMAIL PROTECTED]> wrote: Am I understanding you right that you're installing the same file by two different components with different GUIDs? If they are to the same directory, you'll have ref-counting problems and will loose the component when uninstalling one of the products. Also, if the file is exactly the same and you only authored a single media, it shares the same blob in the embedded cabinet within the MSP. But you said the source directories are different, so this is probably a different file. That means the file will be wrong for one of the products. Adrian Gantoi wrote: > Hi all, > > Still no answers for my problem below. > Doesn't anybody have a clue of what's wrong (why is the wrong > transform applied by the patch) ? > > Thanks, > Adrian > > */Adrian Gantoi /* wrote: > > Hi all, > > Sorry for being so "long" in describing my problem :), but... > I encountered a problem with applying a patch in the following > scenario. > I have a setup project with 2 configurations which I build. > Configuration 1 > - the product has the Product Id GUID1 > - the product has a component with Id COMP and guid GUIDCOMP1 > this component installs a txt file with Id FILE from source dir DIR1 > Configuration 2 > - the product has the Product Id GUID2 > - the product has a component with Id COMP and guid GUIDCOMP2 > this component installs a txt file with Id FILE from source dir DIR2 > This means: > - I have two products (distinct product id) > - I install from each product a component with the same Id but > different GUID > - each component installs a file called FILE.TXT in the same > folder (the contents of the txt file is different between products) > - the two products cannot be installed at the same time > I tryied to create a patch for both products after changing the > txt files (source dir changed from DIR1/DIR2 to DIRUPD1/DIRUPD2) > I used WiX tools only for the patch building process like below: > REM > --- > REM Patch Build - Differences > REM > --- > "%WixDir%\torch.exe" -p -xi Config1\Setup.wixpdb > UPDConfig1\Setup.wixpdb -out diff1.wixmst > "%WixDir%\torch.exe" -p -xi Config2\Setup.wixpdb > UPDConfig2\Setup.wixpdb -out diff2.wixmst > REM > --- > REM Patch build - Compile patch > REM > --- > "%WixDir%\candle.exe&
[WiX-users] Single patch for multiple products
Hi all, Still no answers for my problem below. Doesn't anybody have a clue of what's wrong (why is the wrong transform applied by the patch) ? Thanks, Adrian Adrian Gantoi <[EMAIL PROTECTED]> wrote: Hi all, Sorry for being so "long" in describing my problem :), but... I encountered a problem with applying a patch in the following scenario. I have a setup project with 2 configurations which I build. Configuration 1 - the product has the Product Id GUID1 - the product has a component with Id COMP and guid GUIDCOMP1 this component installs a txt file with Id FILE from source dir DIR1 Configuration 2 - the product has the Product Id GUID2 - the product has a component with Id COMP and guid GUIDCOMP2 this component installs a txt file with Id FILE from source dir DIR2 This means: - I have two products (distinct product id) - I install from each product a component with the same Id but different GUID - each component installs a file called FILE.TXT in the same folder (the contents of the txt file is different between products) - the two products cannot be installed at the same time I tryied to create a patch for both products after changing the txt files (source dir changed from DIR1/DIR2 to DIRUPD1/DIRUPD2) I used WiX tools only for the patch building process like below: REM --- REM Patch Build - Differences REM --- "%WixDir%\torch.exe" -p -xi Config1\Setup.wixpdb UPDConfig1\Setup.wixpdb -out diff1.wixmst "%WixDir%\torch.exe" -p -xi Config2\Setup.wixpdb UPDConfig2\Setup.wixpdb -out diff2.wixmst REM --- REM Patch build - Compile patch REM --- "%WixDir%\candle.exe" Patch.wxs REM --- REM Patch build - Link patch REM --- "%WixDir%\light.exe" Patch.wixobj -out Patch.wixmsp REM --- REM Patch build - Create patch REM --- "%WixDir%\pyro.exe" Patch.wixmsp -out Patch.msp -t RTM diff1.wixmst -t RTM diff2.wixmst The Patch.wxs file contains a ComponentRef to the Id of the tricky component(s) and the general contents is below: The result .msp file, when applied, will update my FILE.TXT installed from the RTM Config1 product to the FILE.TXT included in my updated Config2 product. Installing the patch with logging options shows me something which I cannot understand: ...: Looking for patch transform: RTM.1 ...: Validating transform 'RTM.1' with validation bits 0x922 ...: Note: 1: 2746 2: RTM.1 3: C:\WINDOWS\Installer\49fc6a.msi 4: GUID2 5: GUID1 ...: 1: 2746 2: RTM.1 3: C:\WINDOWS\Installer\49fc6a.msi 4: GUID2 5: GUID1 ...: Note: 1: 2729 DEBUG: Error 2746: Transform RTM.1 invalid for package C:\WINDOWS\Installer\49fc6a.msi. Expected product GUID2, found product GUID1. ...: Skipping validation for patch transform #RTM.1. Will not apply because previous transform was invalid ...: Looking for patch transform: RTM.2 ...: Validating transform 'RTM.2' with validation bits 0x922 ...: Transform 'RTM.2' is valid. I installed the product with GUID1, yet somehow the patch is looking only for the product with GUID2 and applying the transform for GUID2 product. Can somebody let me know where I made the mistake (the identical component id ??) and if I have any chance of patching FILE.TXT with the correct one from a single MSP and without changing the identical component id ? Thanks, Adrian - Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Single patch for multiple products
Doesn't anybody have a clue of whats wrong with this ? Why is the wrong transform installed ? And if I can create a single patch for multiple products (not installable at the same time) if I have in each of them a component with the same Id but different GUID ? - Original Message From: Adrian Gantoi <[EMAIL PROTECTED]> To: wix-users@lists.sourceforge.net Sent: Tuesday, February 12, 2008 12:35:42 PM Subject: [WiX-users] Single patch for multiple products Hi all, Sorry for being so "long" in describing my problem :), but... I encountered a problem with applying a patch in the following scenario. I have a setup project with 2 configurations which I build. Configuration 1 - the product has the Product Id GUID1 - the product has a component with Id COMP and guid GUIDCOMP1 this component installs a txt file with Id FILE from source dir DIR1 Configuration 2 - the product has the Product Id GUID2 - the product has a component with Id COMP and guid GUIDCOMP2 this component installs a txt file with Id FILE from source dir DIR2 This means: - I have two products (distinct product id) - I install from each product a component with the same Id but different GUID - each component installs a file called FILE.TXT in the same folder (the contents of the txt file is different between products) - the two products cannot be installed at the same time I tryied to create a patch for both products after changing the txt files (source dir changed from DIR1/DIR2 to DIRUPD1/DIRUPD2) I used WiX tools only for the patch building process like below: REM --- REM Patch Build - Differences REM --- "%WixDir%\torch.exe" -p -xi Config1\Setup.wixpdb UPDConfig1\Setup.wixpdb -out diff1.wixmst "%WixDir%\torch.exe" -p -xi Config2\Setup.wixpdb UPDConfig2\Setup.wixpdb -out diff2.wixmst REM --- REM Patch build - Compile patch REM --- "%WixDir%\candle.exe" Patch.wxs REM --- REM Patch build - Link patch REM --- "%WixDir%\light.exe" Patch.wixobj -out Patch.wixmsp REM --- REM Patch build - Create patch REM --- "%WixDir%\pyro.exe" Patch.wixmsp -out Patch.msp -t RTM diff1.wixmst -t RTM diff2.wixmst The Patch.wxs file contains a ComponentRef to the Id of the tricky component(s) and the general contents is below: The result .msp file, when applied, will update my FILE.TXT installed from the RTM Config1 product to the FILE.TXT included in my updated Config2 product. Installing the patch with logging options shows me something which I cannot understand: ...: Looking for patch transform: RTM.1 ...: Validating transform 'RTM.1' with validation bits 0x922 ...: Note: 1: 2746 2: RTM.1 3: C:\WINDOWS\Installer\49fc6a.msi 4: GUID2 5: GUID1 ...: 1: 2746 2: RTM.1 3: C:\WINDOWS\Installer\49fc6a.msi 4: GUID2 5: GUID1 ...: Note: 1: 2729 DEBUG: Error 2746: Transform RTM.1 invalid for package C:\WINDOWS\Installer\49fc6a.msi. Expected product GUID2, found product GUID1. ...: Skipping validation for patch transform #RTM.1. Will not apply because previous transform was invalid ...: Looking for patch transform: RTM.2 ...: Validating transform 'RTM.2' with validation bits 0x922 ...: Transform 'RTM.2' is valid. I installed the product with GUID1, yet somehow the patch is looking only for the product with GUID2 and applying the transform for GUID2 product. Can somebody let me know where I made the mistake (the identical component id ??) and if I have any chance of patching FILE.TXT with the correct one from a single MSP and without changing the identical component id ? Thanks, Adrian Looking for last minute shopping deals? Find them fast with Yahoo! Search. -Inline Attachment Follows- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -Inline Attachment Follows- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -
[WiX-users] Single patch for multiple products
Hi all, Sorry for being so "long" in describing my problem :), but... I encountered a problem with applying a patch in the following scenario. I have a setup project with 2 configurations which I build. Configuration 1 - the product has the Product Id GUID1 - the product has a component with Id COMP and guid GUIDCOMP1 this component installs a txt file with Id FILE from source dir DIR1 Configuration 2 - the product has the Product Id GUID2 - the product has a component with Id COMP and guid GUIDCOMP2 this component installs a txt file with Id FILE from source dir DIR2 This means: - I have two products (distinct product id) - I install from each product a component with the same Id but different GUID - each component installs a file called FILE.TXT in the same folder (the contents of the txt file is different between products) - the two products cannot be installed at the same time I tryied to create a patch for both products after changing the txt files (source dir changed from DIR1/DIR2 to DIRUPD1/DIRUPD2) I used WiX tools only for the patch building process like below: REM --- REM Patch Build - Differences REM --- "%WixDir%\torch.exe" -p -xi Config1\Setup.wixpdb UPDConfig1\Setup.wixpdb -out diff1.wixmst "%WixDir%\torch.exe" -p -xi Config2\Setup.wixpdb UPDConfig2\Setup.wixpdb -out diff2.wixmst REM --- REM Patch build - Compile patch REM --- "%WixDir%\candle.exe" Patch.wxs REM --- REM Patch build - Link patch REM --- "%WixDir%\light.exe" Patch.wixobj -out Patch.wixmsp REM --- REM Patch build - Create patch REM --- "%WixDir%\pyro.exe" Patch.wixmsp -out Patch.msp -t RTM diff1.wixmst -t RTM diff2.wixmst The Patch.wxs file contains a ComponentRef to the Id of the tricky component(s) and the general contents is below: The result .msp file, when applied, will update my FILE.TXT installed from the RTM Config1 product to the FILE.TXT included in my updated Config2 product. Installing the patch with logging options shows me something which I cannot understand: ...: Looking for patch transform: RTM.1 ...: Validating transform 'RTM.1' with validation bits 0x922 ...: Note: 1: 2746 2: RTM.1 3: C:\WINDOWS\Installer\49fc6a.msi 4: GUID2 5: GUID1 ...: 1: 2746 2: RTM.1 3: C:\WINDOWS\Installer\49fc6a.msi 4: GUID2 5: GUID1 ...: Note: 1: 2729 DEBUG: Error 2746: Transform RTM.1 invalid for package C:\WINDOWS\Installer\49fc6a.msi. Expected product GUID2, found product GUID1. ...: Skipping validation for patch transform #RTM.1. Will not apply because previous transform was invalid ...: Looking for patch transform: RTM.2 ...: Validating transform 'RTM.2' with validation bits 0x922 ...: Transform 'RTM.2' is valid. I installed the product with GUID1, yet somehow the patch is looking only for the product with GUID2 and applying the transform for GUID2 product. Can somebody let me know where I made the mistake (the identical component id ??) and if I have any chance of patching FILE.TXT with the correct one from a single MSP and without changing the identical component id ? Thanks, Adrian Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Customizable folder name written in registry - lost (reverted to default) on Repair
Hi all, Just found the solution for this. No more need for registry search or custom actions, and also no need to place a file there :) Many thanks to Kalle Olavi Niemitalo (see http://msdn.microsoft.com/newsgroups/default.aspx?dg=microsoft.public.platformsdk.msi&mid=630aeb54-f6f7-4ae6-b8b1-4dad3ba95bac) It works by creating a component which has the folder (TDIR) as KeyPath. Good results then after Repair. Maybe it helps others in the future. Thanks all. Adrian - Original Message From: Bob Arnson <[EMAIL PROTECTED]> To: Adrian Gantoi <[EMAIL PROTECTED]> Cc: wix-users@lists.sourceforge.net Sent: Tuesday, October 9, 2007 5:41:29 AM Subject: Re: [WiX-users] Customizable folder name written in registry - lost (reverted to default) on Repair Adrian Gantoi wrote: Any MSI documentation links for me to understand why the directory property is OK if I have a component with a file as KeyPath installed in that directory and not OK otherwise ? I don't know of any. -- sig://boB http://joyofsetup.com/ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/- 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
Re: [WiX-users] Customizable folder name written in registry - lost (reverted to default) on Repair
Hi Bob, Yes, I saw I needed to do such things, as I wrote in the initial message. I have two workarounds (at least I interpret them as workarounds): registry search and/or standard custom actions (type 51 and 35), both of them working. But I would like to understand first why the directory property is OK if the directory contains an installed file and why not if the directory contains only subfolders. Any MSI documentation links for me to understand why the directory property is OK if I have a component with a file as KeyPath installed in that directory and not OK otherwise ? Regards, Adrian - Original Message From: Bob Arnson <[EMAIL PROTECTED]> To: Adrian Gantoi <[EMAIL PROTECTED]> Cc: wix-users@lists.sourceforge.net Sent: Sunday, October 7, 2007 8:11:04 PM Subject: Re: [WiX-users] Customizable folder name written in registry - lost (reverted to default) on Repair Adrian Gantoi wrote: My problem is that on "Repair" , the registry entry is set to the default name of TDIR, even if this folder was customized at install time. You need to persist customizations and load them back during repair and uninstallation. "Normal" things like files will be repaired and uninstalled normally because MSI records them. So your subdirectory's file is repaired normally but the directory property isn't. The typical approach is to write it to the registry and use RegistrySearch to load it. -- sig://boB http://joyofsetup.com/ Check out the hottest 2008 models today at Yahoo! Autos. http://autos.yahoo.com/new_cars.html- 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
[WiX-users] Customizable folder name written in registry - lost (reverted to default) on Repair
Hi all, I came across a problem with my installer. WiX sources contents below: As you can see, I have two components - a file and a registry value. The file gets installed in [TDIR]\Subdir folder. The registry entry will contain [TDIR]. My problem is that on "Repair" , the registry entry is set to the default name of TDIR, even if this folder was customized at install time. I made some tests and discovered that this DOES NOT happen when the [TDIR] folder contains a file (I added a new component under TDIR with a file as KeyPath). Can anybody help me with this problem ? I failed to find something about this behavior in MSI docs and do not really understand why the folder name is set back to default unless the folder actually contains an installed file. I tried to move the component which writes the registry value directly under TDIR, but this did not help, the folder name is set back to default... Does not seem to work except if a File or IniFile entry exists for this folder in a component... I can workaround this problem by scheduling save [TDIR] / restore TDIR standard custom actions, but I find the need for an workaround a bit rude... At least I want to understand why this happens and if it's a documented issue, or if other solutions exist except custom actions or installing not needed files. Thanks, Adrian Check out the hottest 2008 models today at Yahoo! Autos. http://autos.yahoo.com/new_cars.html- 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
Re: [WiX-users] Explanation for why you can't have both a 32-bit and 64-bit installer
What you can do with MSI : - create an installer which will install Win32 components on Win32 platforms - create an installer which will install x64 and/or Win32 components on x64 platforms You can't however create a single MSI for both Win32 and x64 platforms. Because a MSI must be specified as "for Win32" or "for x64". The Win32 MSI will be installed on a x64 platform (but can install only Win32 components). The x64 MSI will NOT run on Win32 platforms. You will have to create separate Win32 and x64 MSIs (at best, the x64 MSI can install both Win32 and x64 components). Nothing to do with WiX - these are basic limitations of Windows Installer. - Original Message From: OneReallyCoolApplication <[EMAIL PROTECTED]> To: wix-users@lists.sourceforge.net Sent: Monday, October 1, 2007 7:08:06 PM Subject: [WiX-users] Explanation for why you can't have both a 32-bit and 64-bit installer I am supposed to create a MSI package using WiX that can detect whether the computer it's on has 32-bit or 64-bit architecture, and install different files for each. I have browsed Nabble and found replies that say making a single installer that does this is impossible, such as these: http://www.nabble.com/32-and-64-bit-installer-in-one-tf2635209.html http://www.nabble.com/64-bit-newbie-question-tf3979370.html However my boss is not satisfied with this explanation and wants a detailed technical explanation of why WiX or Windows Installer cannot do this. Could any of you give this explanation or perhaps suggest an alternative that I could do? Any links to outside sources would be great, since I suspect my boss doesn't trust Nabble much. Thanks in advance for your help. -- View this message in context: http://www.nabble.com/Explanation-for-why-you-can%27t-have-both-a-32-bit-and-64-bit-installer-tf4549274.html#a12982169 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more! http://tv.yahoo.com/collections/3658 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Advertised shortcut and MSI repair triggered - problems with components reinstalled
Hi all, I have a problem with understanding a MSI feature/behavior. Below is the setup structure. * Feature A * ComponentGroupRef containing: Component A Executable Advertised shortcut to executable, with exe arguments including a file from "Component 1" Component B Registry value containing the install folder for "Feature A" * Feature B Component 1 None of the features can be advertised. I install "Feature A" in folder "F:\Folder1". By default, it would get installed in "C:\Folder1". "Feature B" is installed as by default in "C:\Folder2" - which contains the file sent as argument to the advertised shortcut. The registry value contains at this point "F:\Folder1\". I manually delete "C:\Folder2". Starting the exe from the advertised shortcut triggers MSI repair (at least this is what I understood). The problem is that after MSI finishes repairing my installation, the registry value contains "C:\Folder1\" This looks to be the server side property value Why ? Can anybody point me in the right direction and make me understand my mistake (I hope I made a mistake...) ? Is it a problem in have an advertised shortcut when none of the features can be advertised ? Thanks and regards, Adrian Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Feature element - Condition nightmare
Finally, the light at the end of the tunnel As I expected, turns out I used the FileSearch incorrectly. Unfortunatelly, the WiX / MSI docs are misleading - or better said, the MSI docs are pretty much almost impossible to use and understand from the first read :)). The fact that FileSearch is presented as a posible child of Property is a bit unfortunate... It has to be a child of DirectorySearch to get expected results. Here is the code that DOES work as I intended: - Original Message From: Adrian Gantoi <[EMAIL PROTECTED]> To: Alexei <[EMAIL PROTECTED]>; wix-users@lists.sourceforge.net Sent: Friday, August 17, 2007 9:52:12 AM Subject: Re: [WiX-users] Feature element - Condition nightmare No , it still does not work as I intend. Is it possible to use FileSearch to set a property used in a Condition for a Feature or I started on the wrong road ? - Original Message From: Alexei <[EMAIL PROTECTED]> To: wix-users@lists.sourceforge.net Sent: Thursday, August 16, 2007 2:44:59 PM Subject: Re: [WiX-users] Feature element - Condition nightmare Adrian, I haven't tried this but what I would do is when you declare your Property - omit the Value attribute. This way the property will be undefined. Then when you are checking use something like: <[FOUNDTABCTL32]> This way when the FileSearch finds something then [FOUNDTABCTL32] will be defined and the condition will hold, thereby setting the FeatureToInstallWhenOCXMissing Level="0" Tell me if this helps at all, Alexei Adrian Gantoi wrote: > > Hi all, > > I'm having a problem with correctly specifying the Feature's Condition. > My goal - make a search of an ocx file, and if the ocx file does not exist > on the target computer, > keep a feature selected for installation. > If the ocx exists, the feature should be automatically deselected. > I'm currently having doubts if this is possible, since FileSearch should > return a string... > My code below: > > > > > > >Level="1"> > > > > > > Am I doing something wrong or this is not possible ? > > Thanks for any help, > Adrian > -- View this message in context: http://www.nabble.com/Feature-element---Condition-nightmare-tf4279047.html#a12179726 Sent from the wix-users mailing list archive at Nabble.com. - 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 Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/- 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
Re: [WiX-users] Feature element - Condition nightmare
No , it still does not work as I intend. Is it possible to use FileSearch to set a property used in a Condition for a Feature or I started on the wrong road ? - Original Message From: Alexei <[EMAIL PROTECTED]> To: wix-users@lists.sourceforge.net Sent: Thursday, August 16, 2007 2:44:59 PM Subject: Re: [WiX-users] Feature element - Condition nightmare Adrian, I haven't tried this but what I would do is when you declare your Property - omit the Value attribute. This way the property will be undefined. Then when you are checking use something like: <[FOUNDTABCTL32]> This way when the FileSearch finds something then [FOUNDTABCTL32] will be defined and the condition will hold, thereby setting the FeatureToInstallWhenOCXMissing Level="0" Tell me if this helps at all, Alexei Adrian Gantoi wrote: > > Hi all, > > I'm having a problem with correctly specifying the Feature's Condition. > My goal - make a search of an ocx file, and if the ocx file does not exist > on the target computer, > keep a feature selected for installation. > If the ocx exists, the feature should be automatically deselected. > I'm currently having doubts if this is possible, since FileSearch should > return a string... > My code below: > > > > > > >Level="1"> > > > > > > Am I doing something wrong or this is not possible ? > > Thanks for any help, > Adrian > -- View this message in context: http://www.nabble.com/Feature-element---Condition-nightmare-tf4279047.html#a12179726 Sent from the wix-users mailing list archive at Nabble.com. - 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 Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/- 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
[WiX-users] Feature element - Condition nightmare
Hi all, I'm having a problem with correctly specifying the Feature's Condition. My goal - make a search of an ocx file, and if the ocx file does not exist on the target computer, keep a feature selected for installation. If the ocx exists, the feature should be automatically deselected. I'm currently having doubts if this is possible, since FileSearch should return a string... My code below: Am I doing something wrong or this is not possible ? Thanks for any help, Adrian Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow - 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
Re: [WiX-users] Build 3.0.3210.0 - multiple cabinets problems
Hi Bob, Yes, I saw that and hoped it's a bug :). You confirmed me it's not a bug. However, I beleive this is a bit like "the hard way to do it". It would be a lot more easier to define and use like: - DiskId defined in Directory element - if DiskId missing in DirectoryRef element, default to Directory element DiskId, or if this is missing also to DiskId "1" I eventually packed my files in the right cabs using the DirectoryRef/@DiskId, but I was not happy to have to do it like this. Because I had to update more than 120 wxs files where the DirectoryRefs were. It would have been a lot more easier to maintain in the future and faster to do it in only 10 wxs files which actually define the directory structure. I am pretty sure others have setups with a lot more wxs files than mine,.. so: Is there any chance of getting this behaviour available in the (hopefully close) future? Any chance of it becoming a "feature request" for WiX ? Thanks, Adrian Adrian Gantoi wrote: - I defined several Medias (several cabinets) - I defined the Directory structure - I placed all the Components within DirectoryRefs If I set the DiskId attribute in the Directory elements, all files will end up in the first defined cabinet (and receive warnings about empty cabinets). If I set the DiskId attribute in the DirectoryRef elements, all files are packed in the correct cabinets. Directory/@DiskId cascades only to its children. It doesn't persist outside the fragment, so you can't use a DirectoryRef and have the DiskId previously set cascade to "new" children. The general model is to define your Directory hierarchy in one place and use DirectoryRef/@DiskId when you define your components. -- sig://boB http://joyofsetup.com/ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC- 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
[WiX-users] Build 3.0.3210.0 - multiple cabinets problems
Hi, I need to build a project to output several cabinets. At the moment I have a problem doing this because I found the following bug: - I defined several Medias (several cabinets) - I defined the Directory structure - I placed all the Components within DirectoryRefs If I set the DiskId attribute in the Directory elements, all files will end up in the first defined cabinet (and receive warnings about empty cabinets). If I set the DiskId attribute in the DirectoryRef elements, all files are packed in the correct cabinets. I assume (hope) this is a bug, as I would not want to define the DiskId in the DirectoryRef. It is time consuming (large number of DirectoryRefs to the same directory) and hard to maintain. If required, I can submit a sample wxs file showing the problem. Furthermore, the problem complicates even more when: - I have a MSI project which defines the Media elements - I have several WIXLIB projects included in the MSI project Each WIXLIB defines the Directory, DirectoryRef, Component, File elements. Top-most Directory sets the DiskId attribute. When building the project, I receive errors: .wxs(28): error LGHT0094: Unresolved reference to symbol 'Media:1' in section 'Fragment:'. for each line which contains an File element. Can somebody take a look at this and let me know if I did something wrong ? Is there another WiX build I can use to set the DiskId attribute only in the Directory elements and everything to work OK :)) ?? Thanks for your help, Adrian Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC- 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
[WiX-users] Problem in build 3.0.3210.0 - warnings and errors are not shown detailed in Visual Studio 2005
Hi, Can somebody solve this problem for the next build of WiX v3 ? The warnings and errors are shown only with their numbers, the text of the warning/error is not displayed if the project is built from within Visual Studio 2005. If built from the command-line, the warnings and errors are shown fully. Thanks, Adrian Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ - 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
