[WiX-users] This mailing list has moved to: wix-us...@lists.wixtoolset.org
This mailing list has moved. Please sign up for the wix-us...@lists.wixtoolset.org mailing list. More information can be found here: https://www.firegiant.com/blog/2015/7/21/new-wix-mailing-lists/ -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] File extension association
What does this part mean now the association between the application and its model file is no longer established at installation? ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Moore, Odric M. (MSFC-ER43)[MITS] [mailto:ric.mo...@nasa.gov] Sent: Thursday, July 16, 2015 7:22 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] File extension association I have a WiX 3.7 installation package that is operating fine using perMachine IntallScope. I want to change the installation so that it can be accomplished without admin privilege. Changing to perUser has accomplished that, but now the association between the application and its model file is no longer established at installation. Is this something that is not permitted under perUser? -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Possible Bug: RegDelete does not work properly with REG_KEY_32BIT on a 64-bit system
I think this only happens if you indicate to delete registry tree. You can definitely file the bug but this is probably one of those bugs where it won't get fixed until someone actually needs the fix. So don't file the bug expecting it to be fixed by itself. smile/ ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Edwin Castro [mailto:egca...@gmail.com] Sent: Thursday, July 16, 2015 8:18 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Possible Bug: RegDelete does not work properly with REG_KEY_32BIT on a 64-bit system I can't use semi-custom-actions for this particular piece of work because I need to call an API to get permission to create, delete, or modify these particular registry keys. I work at a security company where they have implemented additional security features through drivers that disallow normal interactions with certain resources. Otherwise, I would totally use the semi-custom-action approach. I use it right now to add rows to the RemoveFile table depending on whether we're uninstalling for an upgrade or not. In any case, RegDelete appears broken to me. At a minimum, the bitness should be incorporated into the RegOpen call. Should I file a bug to track? On Thu, Jul 16, 2015 at 7:01 AM, Phill Hogland phogl...@rimage.com wrote: FYI - I just implemented a semi-custom http://www.joyofsetup.com/2007/07/01/semi-custom-actions/ action using a similar implementation as I found in the WixGamingExtension which calls WcaAddTempRecord on the Registry table, to allow MSI to manage my registry change. The CA code (specifically the registry path) is agnostic to WoW6432Node so that the CA can be built for either Win32 or x64 and used in either a x86 or x64 MSI. I only needed to set Component /@Win64=no and MSI handles the redirection. The MSI packages are also built using the InstallerPlatform MSBuild property to set the bitness of the MSI. For most of the Components I never set Win64, but for this registry key setting Win64=no was needed to get MSI to redirect the the registry hive. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Possible -Bug-RegDelete-does-not-work-properly-with-REG-KEY-32BIT-on-a-64-bit-s ystem-tp7600893p7600896.html Sent from the wix-users mailing list archive at Nabble.com. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Edwin G. Castro -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] «Bundle Uprgade issue: the same MSI in two bundles»
What does the bundle log file show? ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: boroda [mailto:bo.ro...@mail.ru] Sent: Thursday, July 16, 2015 7:25 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] «Bundle Uprgade issue: the same MSI in two bundles» Hello, guys. I have a problem. And the actions of bundle are not obvious. So, I have the follows packages: • MSI ‘MSI_A_v1’ • MSI ‘MSI_B_v1’ • Bundle Bv1, installs MSI_A_v1 and MSI_B_v1. • And MSI ‘MSI_A_v2’ (Major upgrade of ' MSI_A_v1', including changing Product Id) • Bundle Bv2 (the UpgradeCode is the same as the Bv1, but version is upper). Bundle Bv2 installs MSI_A_v2 and MSI_B_v1. My steps: 1. Install Bundle Bv1 2. Install Bundle Bv2. During the installation, MSI_A_v2 is updating MSI_A_v1 (it’s OK), MSI_B_v1 is doing nothing (it’s OK too), and Bv2 is deleting Bv1. It’s OK too, BUT the Bv1’s uninstallation also deletes MSI_B_v1! Why! Bv2 has link to MSI_B_v1, and the product MSI_B_v1 should remain on system. This is the main problem, after installation, the MSI_B_v1 is not on the system -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] .NET Prerequisite, Burn, and the ARP
Yes. There are very good reasons why Burn behaves the way it does today and handling this case requires additional (non-trivial) code (not fixing existing code). ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Jiri Tomek [mailto:katu...@volny.cz] Sent: Monday, July 13, 2015 3:23 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] .NET Prerequisite, Burn, and the ARP So just to make sure, the current behavior is kind of by design and currently there is no way how to not get ARP entry if .NET prereqba succeeds? It needs to be implemented as a new feature to Burn? -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Why Does Bundle Prompt For Source During Uninstall?
The attached container is stripped (to save [often signification] disk space).
Look higher in the log to see what package is requesting to be cached during
uninstall. Probably an ExePackage.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Edwin Castro [mailto:egca...@gmail.com]
Sent: Monday, July 13, 2015 4:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Why Does Bundle Prompt For Source During Uninstall?
I have a bundle that I have successfully installed. When I try to uninstall I
get the following:
[0E54:03D0][2015-07-13T15:34:03]i300: Apply begin
[07F0:0814][2015-07-13T15:34:03]i360: Creating a system restore point.
[07F0:0814][2015-07-13T15:34:10]i361: Created a system restore point.
[0E54:01C4][2015-07-13T15:34:10]w341: Prompt for source of container:
WixAttachedContainer, path: C:\Original\path\to\bundle\setup.exe
[0E54:01C4][2015-07-13T15:34:10]e054: Failed to resolve source for
file: C:\Original\path\to\bundle\setup.exe, error: 0x80070643.
[0E54:01C4][2015-07-13T15:34:10]e000: Error 0x80070643: Failed while prompting
for source (original path 'C:\Original\path\to\bundle\setup.exe').
[0E54:01C4][2015-07-13T15:34:10]e311: Failed to acquire container:
WixAttachedContainer to working path:
C:\Windows\TEMP\{e2007576-a648-4b3f-8e4d-eccd898e4591}\75A375A2F5B5EE0C8914C4790878E0D2772E4838,
error: 0x80070643.
[0E54:03D0][2015-07-13T15:34:10]e000: Error 0x80070643: Failed while caching,
aborting execution.
[0E54:03D0][2015-07-13T15:34:10]i399: Apply complete, result: 0x80070643,
restart: None, ba requested restart: No
[0E54:03D0][2015-07-13T15:34:11]i500: Shutting down, exit code: 0x643
I checked C:\ProgramData\Package Cache to make sure my bundle was still cached
(it was).
Under what circumstances does the burn engine try to resolve the original
bundle location?
I was under the impression that the bundle was cached at C:\ProgramData\Package
Cache to avoid needing the original source to be available.
--
Edwin G. Castro
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] .NET Prerequisite, Burn, and the ARP
Cool. It's a very big feature. So you'll want to do all this first: http://wixtoolset.org/development/ Also, a WIP (http://wixtoolset.org/development/wips/-wix-improvement-proposal/) will definitely be in order. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: soundararajan dhakshinamoorthy [mailto:er.soundarara...@gmail.com] Sent: Thursday, July 9, 2015 7:48 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] .NET Prerequisite, Burn, and the ARP Hi, Added the issue , http://wixtoolset.org/issues/4822 We will try to contribute to the issue :-). Thanks, Sound On Thu, Jul 9, 2015 at 10:02 AM, Rob Mensching r...@firegiant.com wrote: Add feature to Burn. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: soundararajan dhakshinamoorthy [mailto:er.soundarara...@gmail.com] Sent: Wednesday, July 8, 2015 6:37 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] .NET Prerequisite, Burn, and the ARP Hi Rob, Do you have any advice on how to handle prerequisites (not prereqmba) without adding an entry ? Thanks in advance Sound -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- -Soundararajan Dhakshinamoorthy -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Customized downloaded MSI location
At least in WiX v3.10 (maybe v3.9) you can set the package cache location via policy: HKLM\SOFTWARE\Policies\WiX\Burn@PackageCache That is a machine wide setting for users that need to move the package cache to a different drive. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Mohamed Yasir [mailto:yasirmohame...@gmail.com] Sent: Sunday, March 8, 2015 10:50 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Customized downloaded MSI location Hi, Consider following scenario, Sum of Download Size and Installation size having more than the System Drive available size. In this case, user having enough space for installation files. But not having space for store the downloaded files in system drive. So want to change the download location. Could you please share any idea to change the package download location? Is it possible to change download location. Regards, Mohamed Yasir K -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Customized-downloaded-MSI-location-tp7597899p7599500.html Sent from the wix-users mailing list archive at Nabble.com. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Two Different Bundles, Same MSI, Upgrade and Bundle Dependencies.
In this scenario, Bv1 needs to be repaired. Hard unsolved problem to do better than that. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: speirscd [mailto:speirs...@gmail.com] Sent: Wednesday, July 8, 2015 10:27 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Two Different Bundles, Same MSI, Upgrade and Bundle Dependencies. The main problem is that in the below scenario an MSI is uninstalled after it is upgraded by a second installer and that second installer is uninstalled. In brief this appears to be a problem with not upgrading package dependencies in a multiple bundle and major upgrade scenario. *The scenario:* Existing Installers: MSI 'Mv1'. Bundle 'Av1' installs 'Mv1'. Bundle 'Bv1' installs 'Mv1'. MSI 'Mv2'. (Major upgrade of 'Mv1', including changing Product Id) Bundle 'Av2' installs 'Mv2'. (Upgrade bundle of 'Av1') Actions: Install Bv1. Mv1 is installed. Install Av2. Mv2 is installed by upgrading Mv1 to Mv2. Uninstall Av2. Mv2 is found to not have other dependencies, Mv2 is removed. Mv1 is not on the system Bv1 is no longer functional because Mv1 (or later) does not exist. *Query:* Is this an intended limitation? Is a major upgrade not feasible in this case where there exists two bundles installing/upgrading the same MSI? https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] .NET Prerequisite, Burn, and the ARP
Ahh, the prereqba completed successfully. So the bundle was successfully
installed before being restarted to load the ManagedBA. That basically makes
sense.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Jiri Tomek [mailto:katu...@volny.cz]
Sent: Wednesday, July 8, 2015 1:02 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] .NET Prerequisite, Burn, and the ARP
Hello,
I have the same issue. I double-checked that .NET package is marked as
permanent and I tried both with and without rollback boundary but I still get
ARP entry right after .NET is installed as prerequisite. I'm using Wix 3.9.
My Chain is defined this way:
Chain
PackageGroupRef Id=NetFx45Redist/
RollbackBoundary /
PackageGroupRef Id=TestPackage /
/Chain
The log from initial run is this:
[0690:0168][2015-07-08T00:29:07]i001: Burn v3.9.1006.0, Windows v6.1 (Build
7601: Service Pack 1), path:
C:\Users\Administrator\Desktop\TestInstaller.exe, cmdline: '-burn.unelevated
BurnPipe.{4303C9F0-DB96-41D1-A217-26466A0A9178}
{253C2727-CA99-43F7-B8B1-CF0835E221F0} 380 '
... snip ...
[0690:0168][2015-07-08T00:29:07]i000: Loading prerequisite bootstrapper
application because managed host could not be loaded, error: 0x80070490.
[0690:0464][2015-07-08T00:29:07]i000: Setting version variable
'WixBundleFileVersion' to value '1.0.0.0'
[0690:0168][2015-07-08T00:29:07]i100: Detect begin, 2 packages
[0690:0168][2015-07-08T00:29:07]i000: Registry key not found. Key =
'SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full'
[0690:0168][2015-07-08T00:29:07]i052: Condition 'PreviousInstallFolder'
evaluates to false.
[0690:0168][2015-07-08T00:29:07]i052: Condition 'NETFRAMEWORK45 = 378389'
evaluates to false.
[0690:0168][2015-07-08T00:29:07]i101: Detected package: NetFx45Redist,
state: Absent, cached: None
[0690:0168][2015-07-08T00:29:07]i101: Detected package: TestPackage, state:
Absent, cached: None
[0690:0168][2015-07-08T00:29:07]i199: Detect complete, result: 0x0
[0690:0168][2015-07-08T00:29:09]i200: Plan begin, 2 packages, action:
Install
[0690:0168][2015-07-08T00:29:09]w321: Skipping dependency registration on
package with no dependency providers: NetFx45Redist
[0690:0168][2015-07-08T00:29:09]i000: Setting string variable 'NetFx45FullLog'
to value
'C:\Users\ADMINI~1\AppData\Local\Temp\TestInstaller_20150708002907_0_NetFx45Redist.log'
[0690:0168][2015-07-08T00:29:09]i201: Planned package: NetFx45Redist, state:
Absent, default requested: Present, ba requested: Present, execute: Install,
rollback: None, cache: Yes, uncache: No, dependency: None
[0690:0168][2015-07-08T00:29:09]i201: Planned package: TestPackage, state:
Absent, default requested: Absent, ba requested: None, execute: None,
rollback: None, cache: No, uncache: No, dependency: None
[0690:0168][2015-07-08T00:29:09]i299: Plan complete, result: 0x0
[0690:0168][2015-07-08T00:29:09]i300: Apply begin
[017C:054C][2015-07-08T00:29:09]i360: Creating a system restore point.
[017C:054C][2015-07-08T00:29:09]i362: System restore disabled, system restore
point not created.
[017C:054C][2015-07-08T00:29:09]i000: Caching bundle from:
'C:\Users\ADMINI~1\AppData\Local\Temp\{380d557e-ec88-4923-9924-a37299972102}\.be\TestInstaller.exe'
to: 'C:\ProgramData\Package
Cache\{380d557e-ec88-4923-9924-a37299972102}\TestInstaller.exe'
[017C:054C][2015-07-08T00:29:09]i320: Registering bundle dependency
provider: {380d557e-ec88-4923-9924-a37299972102}, version: 1.0.0.0
[017C:0504][2015-07-08T00:29:09]i305: Verified acquired payload:
NetFx45Redist at path: C:\ProgramData\Package Cache\.unverified\NetFx45Redist,
moving to: C:\ProgramData\Package
Cache\CD57380514DC157DF75A09D3E54C96D1DF3DF51A\redist\dotnetfx45_full_x86_x64.exe.
[017C:054C][2015-07-08T00:29:09]i301: Applying execute package:
NetFx45Redist, action: Install, path: C:\ProgramData\Package
Cache\CD57380514DC157DF75A09D3E54C96D1DF3DF51A\redist\dotnetfx45_full_x86_x64.exe,
arguments: 'C:\ProgramData\Package
Cache\CD57380514DC157DF75A09D3E54C96D1DF3DF51A\redist\dotnetfx45_full_x86_x64.exe
/q /norestart /ChainingPackage Test Installer /log
C:\Users\ADMINI~1\AppData\Local\Temp\TestInstaller_20150708002907_0_NetFx45Redist.log.html'
[0690:0168][2015-07-08T00:33:20]i319: Applied execute package:
NetFx45Redist, result: 0x0, restart: None
[0690:0168][2015-07-08T00:33:20]i399: Apply complete, result: 0x0, restart:
None, ba requested restart: No
[0690:0168][2015-07-08T00:33:20]i500: Shutting down, exit code: 0x0
[0690:0168][2015-07-08T00:33:20]i000: The prerequisites were successfully
installed. The bootstrapper application will be reloaded.
[0690:0168][2015-07-08T00:33:20]i006: Bootstrapper application requested to be
reloaded.
[0690:0168][2015-07-08T00:33:20]i000: Loading managed bootstrapper application.
[0690:0168][2015-07-08T00:33:20]i000: Creating BA thread to run asynchronously.
Re: [WiX-users] .NET Prerequisite, Burn, and the ARP
Add feature to Burn. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: soundararajan dhakshinamoorthy [mailto:er.soundarara...@gmail.com] Sent: Wednesday, July 8, 2015 6:37 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] .NET Prerequisite, Burn, and the ARP Hi Rob, Do you have any advice on how to handle prerequisites (not prereqmba) without adding an entry ? Thanks in advance Sound -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn: External dependencies?
Playing with fire writing to the Windows Installer's private data but I don't have other ideas if old chainer doesn't have a sharing mechanism. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Reuss, Matthias [mailto:matthias.mr.re...@sivantos.com] Sent: Monday, July 6, 2015 3:47 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Burn: External dependencies? Hello, we are migrating from another chained MSI installation (in fact we used ISChainer, but I do not think that matters) to Burn. There are several bundles that may be installed in parallel and that share some of their packages. With WiX 3.9R2, the dependencies among these Burn bundles are treated well without extra coding. I.e. I install Bundle1 and Bundle2 that both contain a SharedProduct, than I uninstall one of the bundles, and the shared product remains. However, we also have to treat the use case that an old-style chained installation and a Burn bundle coexist. Is there a built-in way (with or without using the Dependency extension) to handle such dependencies? In the old-style chain, we mimic Burn's dependency-keeping behaviour by a dummy flag component in the root of the chain that is installed if the associated chained package is installed and an uninstall condition for the chained product that inhibits uninstallation if this component has other clients (Uninstall if $GUID=2) Our current approach to build the bridge between the old and the new chain is that the CustomBA adds a new value to the component entry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\CompressedComponentGUID for the flag component and removes it again on uninstallation, so that uninstallation of the old-style chain will not remove the product. I know that this is ugly, but I do not see another solution. On uninstallation, the CustomBA also looks whether the flag component is still used by other products to determine whether to uninstall the shared product. Best regards Matthias Reuss -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Error 0x80070057: Failed to parse @Code value: -1
I was looking at HEAD. Bug fix in WiX v3.9 or v3.10? ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: CastroAlicea, Edwin [mailto:edwin_castroali...@mcafee.com] Sent: Thursday, July 2, 2015 5:42 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Error 0x80070057: Failed to parse @Code value: -1 Ok, that's really weird. That's not what I see at all. ExitCodeInfo.cs:38:this.Code = value.ToString(); I'm looking at wix38rtm. Does WiX 3.8.1128.0 not correspond to wix38rtm? -- Edwin G. Castro -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ExecSecureObjects action need very long time
Lots of files in the folder? _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: thomas.deboben@rohde-schwarz.com [mailto:thomas.deboben@rohde-schwarz.com] Sent: Thursday, July 2, 2015 1:30 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] ExecSecureObjects action need very long time Hi, no one there who could give me a hint? Best regards, Thomas -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ExecSecureObjects action need very long time
Yeah, okay then. Resetting the ACLs on lots and lots of files can take lots and lots of time. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: thomas.deboben@rohde-schwarz.com [mailto:thomas.deboben@rohde-schwarz.com] Sent: Thursday, July 2, 2015 2:22 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] ExecSecureObjects action need very long time Hi Rob, on one system yes 1.3 million files so the installer run 40 min. After removing these files the installer performed fine again. On the other system where I added the trace infos onle 215 files with 55MB. Cheers, Thomas -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] upgrade fails with 1612 error
It appears the old MSI requires it's source (that's a big no-no on uninstall).
Can you successfully uninstall it directly (i.e. not via an upgrade)?
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: gapearce [mailto:mr_gapea...@yahoo.com]
Sent: Tuesday, June 30, 2015 9:41 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] upgrade fails with 1612 error
I have a machine where I cannot upgrade my old product to the new version.
It is just on this one machine - it has successfully upgraded on many other
machines of the same version of windows.
Thanks in advance if anyone can tell me why this happens (it is intermittent
even on the same machine).
User is admin, and the upgrade code has never changed. Product code is
different every time I build the installer.
Here is the (most obviously to me) relevant part of the msi log:
MSI (s) (84:70) [11:31:34:536]: SOURCEMGMT: Media enabled only if package is
safe.
MSI (s) (84:70) [11:31:34:536]: SOURCEMGMT: Looking for sourcelist for product
{BDAE80A8-5F58-46A9-BDD0-1297BC21CC46}
MSI (s) (84:70) [11:31:34:536]: SOURCEMGMT: Adding
{BDAE80A8-5F58-46A9-BDD0-1297BC21CC46}; to potential sourcelist list
(pcode;disk;relpath).
MSI (s) (84:70) [11:31:34:536]: SOURCEMGMT: Now checking product
{BDAE80A8-5F58-46A9-BDD0-1297BC21CC46}
MSI (s) (84:70) [11:31:34:536]: SOURCEMGMT: Media is enabled for product.
MSI (s) (84:70) [11:31:34:536]: SOURCEMGMT: Attempting to use LastUsedSource
from source list.
MSI (s) (84:70) [11:31:34:536]: SOURCEMGMT: Trying source
C:\Users\Administrator\AppData\Roaming\Access\Setup\.
MSI (s) (84:70) [11:31:34:536]: SOURCEMGMT: Source is invalid due to invalid
package code (product code doesn't match).
MSI (s) (84:70) [11:31:34:536]: Note: 1: 1706 2: -2147483646 3:
Setup_AACU.msi
MSI (s) (84:70) [11:31:34:536]: SOURCEMGMT: Processing net source list.
MSI (s) (84:70) [11:31:34:536]: Note: 1: 1706 2: -2147483647 3:
Setup_AACU.msi
MSI (s) (84:70) [11:31:34:536]: SOURCEMGMT: Processing media source list.
MSI (s) (84:70) [11:31:35:458]: Note: 1: 2303 2: 87 3: A:\ MSI (s) (84:70)
[11:31:35:458]: SOURCEMGMT: Trying media source D:\.
MSI (s) (84:70) [11:31:35:458]: Note: 1: 2203 2: D:\Setup_AACU.msi 3:
-2147287038
MSI (s) (84:70) [11:31:35:458]: SOURCEMGMT: Source is invalid due to
missing/inaccessible package.
MSI (s) (84:70) [11:31:35:458]: SOURCEMGMT: Trying media source A:\.
MSI (s) (84:70) [11:31:35:552]: Note: 1: 1325 2: Setup_AACU.msi MSI (s) (84:70)
[11:31:35:552]: Note: 1: 1706 2: -2147483647 3:
Setup_AACU.msi
MSI (s) (84:70) [11:31:35:552]: SOURCEMGMT: Processing URL source list.
MSI (s) (84:70) [11:31:35:552]: Note: 1: 1402 2: UNKNOWN\URL 3: 2 MSI (s)
(84:70) [11:31:35:552]: Note: 1: 1706 2: -2147483647 3:
Setup_AACU.msi
MSI (s) (84:70) [11:31:35:552]: Note: 1: 1706 2: 3: Setup_AACU.msi MSI (s)
(84:70) [11:31:35:552]: SOURCEMGMT: Failed to resolve source MSI (s) (84:1C)
[11:31:35:552]: Note: 1: 1714 2: Access Configuration Utility 3: 1612
CustomAction returned actual error code 1612 (note this may not be 100%
accurate if translation happened inside sandbox) MSI (s) (84:1C)
[11:31:35:552]: Product: Access Configuration Utility -- Error 1714. The older
version of Acronis Access Configuration Utility cannot be removed. Contact your
technical support group. System Error 1612.
Thanks in advance...
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] 32 vs 64 bit MSI?
Yes, MSIs declare the architecture they support. X86 MSIs can't write to x64 locations. MSIs that target Alpha (now long deprecated) can't install on x86 or x64 or ia64 (also now deprecated?). See the -arch cmd-line switch and Win64 attributes on various elements. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Walter Dexter [mailto:wfdex...@gmail.com] Sent: Monday, June 29, 2015 2:51 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] 32 vs 64 bit MSI? I know this isn't really specifically WiX related, but I also know you guys know lots of MSI and installer stuff. I'm seeing references to 32-bit MSIs vs. 64-bit MSIs. Is there actually something inherently architecture-related about an MSI, or is it just a matter of the 32/64 nature of the programs it installs? I could see it getting messy figuring out which part of the registry to put stuff in for 32 vs. 64 bit programs on a 64-bit platform, so I guess Windows Installer would need to know where to do registry entries. But how does it tell? Thanks! -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Does Burn allow minor upgrades of packages? [P]
Burn handles minor upgrades. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Reuss, Matthias [mailto:matthias.mr.re...@sivantos.com] Sent: Friday, June 26, 2015 6:20 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Does Burn allow minor upgrades of packages? [P] Hi Steve, Thanks for your reply. I have been developing MSI installations for a couple of years, and I am familiar with the differences between minor and major upgrades and where to use each of them. We rather need to deploy minor upgrades as full installers (besides the patches), and my question was whether Burn allows an upgrade installation of a bundle where (some or all of) the packages are minor upgrades. So Bundle v1.0 contains MsiPackageA v5.0, MsiPackageB v6.0 Bundle v1.1 contains MsiPackageA v5.1, MsiPackageB v6.1, both with unchanged ProductCodes Best regards Matthias Reuss -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Why does a patch build include same versioned dlls?
IIRC, there is a feature request open to do smarter binary diffing. If not, seems like a reasonable feature request to open. In either case, perhaps you would like to implement this feature? If not, you will be waiting for someone else to do so. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Jakob Ziegler [mailto:subscr...@gmail.com] Sent: Thursday, June 25, 2015 12:31 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Why does a patch build include same versioned dlls? Hi thanks for the answers, but they unfortunately don't answer my question. Is there a reason/rationale behind this patch creation behavior? Or did the patch appliance rules change at some point while the patch creation logic was left untouched? Cheers Jakob ps: apart from specifying which components to include in a patch, we automated that by using the original files to create the updated installer, and just replace the libs of which we touched the code (we mustn't forget to set a higher file version, of course). It takes responsibility from the devs to know about components and installer/patching etc. Most don't care, unfortunately. Still, it looks to me as if we are going to great lengths to get a patch built in a way so that it doesn't carry already deployed libraries, which differ only by the teeniest amount on the binary lvl. -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Not to create key under HKCU path in the registry
I think this applies: http://robmensching.com/blog/posts/2007/4/27/how-to-create-an-uninstall-shortcut-and-pass-all-the/ _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Manoj Rawat [mailto:mangb...@gmail.com] Sent: Thursday, June 25, 2015 1:27 AM To: General discussion about the WiX toolset.; nir@panel-sw.com Subject: Re: [WiX-users] Not to create key under HKCU path in the registry Hi Nir, I changed root path to HKLM and got below errors. ICE38: Component TestWindowServiceShortcut installs to user profile. It's KeyPath registry key must fall under HKCU. ICE43: Component TestWindowServiceShortcut has non-advertised shortcuts. It's KeyPath registry key should fall under HKCU. ICE57: Component 'TestWindowServiceShortcut' has both per-user and per-machine data with a per-machine KeyPath. Thanks, Manoj -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to Allow Same Version Upgrades in Bundles
Any BA can choose to allow same version upgrades. The wixstdba does not. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Edwin Castro [mailto:egca...@gmail.com] Sent: Tuesday, June 23, 2015 1:58 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] How to Allow Same Version Upgrades in Bundles I'm trying to implement same version upgrades in our bootstrapper. We build our product in one build process and later create the installers in a second package process. This allows us to repackage our product when fixing installer changes that do not affect the product in any other way. We do not change our versions when we repackage. I found that instead of upgrading the existing bundle installation, the new bundle is installed separately resulting in two ARP entries. I found feature http://wixtoolset.org/issues/3746/ requesting that burn support same version upgrades. Feature 3746 is listed as Untriaged and had been opened for a very long time. I expect this means an official fix is not coming soon. Are there any workarounds for supporting same version upgrades in bundles? -- Edwin G. Castro -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to Allow Same Version Upgrades in Bundles
Not today. Creating the same bundle with the same version just isn't something wixstdba considers a real scenario today. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Edwin Castro [mailto:egca...@gmail.com] Sent: Tuesday, June 23, 2015 3:06 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] How to Allow Same Version Upgrades in Bundles Conversely, is there a way to DISALLOW same version upgrades in bundles using wixstdba? I'm trying to figure out what my options are. -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to Uninstall ExePackage Only During Uninstall
Give it a Provides element from Dependency Extension to enable reference tracking. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Edwin Castro [mailto:egca...@gmail.com] Sent: Tuesday, June 23, 2015 4:06 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] How to Uninstall ExePackage Only During Uninstall My ExePackage gets uninstalled during upgrades and I'd like to only uninstall during an actual uninstall. Any suggestions on how I might go about doing this? I was hoping I could do something in my bafunctions.dll but I'm hitting a wall in my brainstorming. My bundle consists of the following: * A few pre-requisites (A) that will remain on the system after uninstall * A pre-requisite ExePackage (B) that will be uninstalled only when my product MSI is uninstalled * My product MSI (C) The package order in the chain is as follows: chain PackageGroupRef Id=A/ PackageGroupRef Id=B/ PackageGroupRef Id=C/ /chain B is an ExePackage that has DetectCondition and InstallCondition set. During an install or uninstall the packages run in the expected order: * Install: A, B, C * Uninstall: C, B However, during an upgrade I get an undesired order. A and B are not upgraded because they are detected as already existing at the correct version. C is upgraded to the new version. The last thing the new bundle does is to uninstall the related bundle. In the log for the related bundle uninstall I see that B is marked as Obsolete so it is uncached and unregistered. BUT C is detected as Present and is thus selected to be uninstalled. * Upgrade: C, UninstallRelatedBundle(B) I'd like to only uninstall B when C is uninstalled. I think I have my DetectCondition setup properly to install B when the new bundle contains a new version of B. However, I never want to uninstall B during an upgrade. B should be uninstalled only during an uninstall. -- Edwin G. Castro -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] When is Wix 3.10 publicly available ?
PS: WiX v3.10 is available now: http://wixtoolset.org/releases/ ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Phill Hogland [mailto:phogl...@rimage.com] Sent: Monday, June 22, 2015 5:07 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] When is Wix 3.10 publicly available ? Those issues are discussed in the weekly on-line meeting, Tuesday evening, and summarized in this blog https://www.firegiant.com/blog/2015/6/16/wix-online-meeting-70-highlights/ . If I recall from the comments in the last meeting, the 'RC' will be announced soon. The stable release is expected to wait until after the Microsoft release of VS2015 is completed. Subsequently it is likely that there will be 'service releases' of 3.10.n rather than a focus on a 3.11 (or 3.1x) and a focus on the 4.x efforts. But those are issues which are discussed in the weekly meeting on, Tuesday evening, and I think all are welcome to participate. -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Windows Installer Cache - gone!
Yeah, nothing to be done but to be clear you might be unhappily surprised when the original MSI is requested during an upgrade because Windows Installer can't find the it in the cache. Might want to stop deleting the cache. smile/ ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Walter Dexter [mailto:wfdex...@gmail.com] Sent: Thursday, June 18, 2015 10:26 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Windows Installer Cache - gone! I don't do patches. Nobody does patches for this platform - it isn't worth the effort. The MSIs aren't installed interactively - ever. Strictly Microsoft system management tools and our own home-grown extensions. We have the worst case of NIH syndrome ever. Thanks for the feedback, mostly just wanted a sanity check from someone more experienced with this stuff that there's really nothing to be done. :) -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Detect Bundle-driven installation?
Nope. Easy enough for you to do it rather than force a feature on everyone that doesn't need it. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Reuss, Matthias [mailto:matthias.mr.re...@sivantos.com] Sent: Wednesday, June 17, 2015 3:40 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Detect Bundle-driven installation? Hello, Is there a built-in way for an MSI package to detect that it was started from a Bundle? (E.g. a property that Burn automatically sets) We are going to set such a property using an MSIProperty element, but if that feature is already built-in, we don't need to do it ourselves. Best regards Matthias Reuss -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using arbitrary shell folders as the target Directory
If your app is system wide then you probably should set ALLUSERS=1. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Todd Hartman [mailto:t...@machmotion.com] Sent: Monday, June 15, 2015 12:22 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Using arbitrary shell folders as the target Directory Is there a way to specify an arbitrary shell folder as a Directory attribute (e.g. in a Shortcut element)? For example, I don't want to use ALLUSERS. My app is system-wide. I want to make Start Menu shortcuts for all users. There's not a Built-In variable for this. Is there a general way to specify a shell folder name/value or have Wix do the lookup at install time (e.g. using CSIDL_COMMON_STARTMENU)? todd. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Getting WixBundleLog Timestamp
See the ExePackage/@LogPathVariable attribute _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Edwin Castro [mailto:egca...@gmail.com] Sent: Monday, June 15, 2015 9:09 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Getting WixBundleLog Timestamp Is there a way to get the timestamp used in the WixBundleLog? I'd like to use it as part of the log filename in the InstallCommand and/or UninstallCommand of the ExePackages in my Bundle. -- Edwin G. Castro -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Removing files as part of upgrade
Component/@Guid must be globally stable (the global part of global unique identifier should kinda' hint at that). Component/@Id must be stable for patching/minor upgrades. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] Sent: Friday, June 12, 2015 10:32 AM To: keith.doug...@statcan.gc.ca; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Removing files as part of upgrade (Thanks to Rob's post, too.) But: I am not sure why I read both the post, the WiX documentation (under Component), but it sounds like to me that the Guid attribute on Component is what is supposed to be stable, not the ComponentId. Nevertheless, I have written a new mechanism for generating the ComponentIds for our front end, which will include the version of the package so when the product is upgraded we can generate a new one for each item. Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-854-5589 Facsimile | Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada -Original Message- From: Douglas, Keith - CoSD/DSCo Sent: June-12-15 12:03 PM To: General discussion about the WiX toolset. Subject: RE: Removing files as part of upgrade Oh, you have to generate a new component ID? Is that the trick? I had forgotten that. Hm, that's going to be interesting for our front end thing to keep track of, since it makes componentids as it goes for everything so that the WXS can be automatically generated from a list of files and various rules and such. Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-854-5589 Facsimile | Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada -Original Message- From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Sent: June-12-15 11:57 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Removing files as part of upgrade If the app is modifying the files, the RemoveFIle should be in the MSI for the version that installed the file. The real question is why is your app modifying the installed files. Could it not be changed to use the default file if an override didn't exist? Then have the app copy the installed file to a per-user/per-machine common app folder, for the customizations? If you are renaming files, as long as you follow the component rules, a major upgrade should remove the old file and apply the new one. (IE, the old file and new file, should not share the same component ID.) -Original Message- From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] Sent: Friday, June 12, 2015 10:48 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Removing files as part of upgrade We have some applications which will be changing the actual files they install as they upgrade in the sense that new names will be used. I notice that my default way of doing the upgrades does not *delete* the old ones. (I.e., creating a new WXS with the same upgrade code as the old one but with new components, etc.) What's the best way to go about doing this? Do I have to put in a RemoveFile for everything?? What if the directory changes? Keith Douglas Programmer Analyst | Programmeur analyste Questionnaire Development Services - CAI Social | Services de développement de questionnaires - IAO Social Jean Talon Building | Immeuble Jean-Talon / Floor | Étage 4 A-3 Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-854-5589 Facsimile | Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --
Re: [WiX-users] Removing files as part of upgrade
You should read: http://robmensching.com/blog/posts/2003/10/18/component-rules-101/ _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] Sent: Friday, June 12, 2015 9:03 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Removing files as part of upgrade Oh, you have to generate a new component ID? Is that the trick? I had forgotten that. Hm, that's going to be interesting for our front end thing to keep track of, since it makes componentids as it goes for everything so that the WXS can be automatically generated from a list of files and various rules and such. Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-854-5589 Facsimile | Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to rollback installation after ApplyComplete event
No. ApplyComplete means the apply is complete. If you want something to participate in the transaction put it in the Chain. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Jiri Tomek [mailto:katu...@volny.cz] Sent: Thursday, June 11, 2015 7:32 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to rollback installation after ApplyComplete event Hello, I do some post-install configuration of installed product as part of installation and for user it still looks like install itself. When I got ApplyComplete event and I know that product is installed I run configuration that may take few minutes. I still want to allow user to cancel it and cancel whole installation. Is it possible to somehow tell Burn to rollback installation if it already passed ApplyComplete state? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-rollback-installation-after-ApplyComplete-event-tp7600608.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 3.x and 4.0 roadmap for 2015
Generally, roadmap stuff is discussed on wix-devs and the WiX Online Meetings (since most of the drivers of the project show up there). _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Robert Flaming [mailto:rflam...@exchange.microsoft.com] Sent: Thursday, June 11, 2015 9:15 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] WiX 3.x and 4.0 roadmap for 2015 Thanks Phil for sharing your insights. I see this blog post reports what will happen with 3.10 which anticipates releasing in next few months. I remain curious about the intentions for 3.x beyond 3.10 and for 4.0 overall. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patches no longer working for a specific RTM using WiX 3.7 + Pure WiX Patching
It will probably work but you may hit issues building patches. Nothing specific comes to mind. If you hit issue, you can upgrade using latest toolset then start patching again. Generally speaking, one should not change tooling when patching. That goes for all tools, versions of Visual Studio, compilers, etc. Too much churn can occur. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Tunney, Stephen [mailto:stephen.tun...@nuance.com] Sent: Wednesday, June 10, 2015 11:06 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Patches no longer working for a specific RTM using WiX 3.7 + Pure WiX Patching Sorry, posted that last one to the wrong conversation :( Rob et. al. I have a question regarding upgrading WiX. We have several RTMs that have been produced using 3.7 and 3.9. Is it supported to move producing updated installers+patches to newer versions of WiX? My concern is that I don't want to have a large number of WiX versions floating around as both WiX and our own products mature over time. Thanks, Stephen -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patches no longer working for a specific RTM using WiX 3.7 + Pure WiX Patching
Validating the provided .wixpdb actually goes with the .MSI seems like a good
idea.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Tunney, Stephen [mailto:stephen.tun...@nuance.com]
Sent: Wednesday, June 10, 2015 6:37 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Patches no longer working for a specific RTM using WiX
3.7 + Pure WiX Patching
Well after a week of wasting my time on this it turns out we had a file restore
of a IT-Special kind. They restore the wixpdb folder to the WRONG directory.
This meant that the wixpdb files didn't match up with the MSIs that we were
melting against and this caused the issues downstream.
Can we add validation of things like ProductCode, Version, UpgradeCode to melt
please when a wixpdb is provided with the MSI?
This would have saved folks a HUGE amount of time and I think is an essential
part of validating a pair of files are meant to be together.
-Original Message-
From: Tunney, Stephen [mailto:stephen.tun...@nuance.com]
Sent: June-09-15 1:56 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Patches no longer working for a specific RTM using WiX
3.7 + Pure WiX Patching
I've been digging a lot deeper into what is going on when installing the
product vs. applying the patch.
Running procmon.exe (sysinternals) I see that the product is being registered
here:
HKCR\Installer\Products\BA2E5E0A5A687F244A67FD7AC4440CC2
HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\BA2E5E0A5A687F244A67FD7AC4440CC2\InstallProperties
The UpgradeCode is here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UpgradeCodes\CC10F1EC4984F7947A3470DD3A64810E\
BA2E5E0A5A687F244A67FD7AC4440CC2 (REG_SZ)
But when the patch is run it is looking for the product in the following
locations (and can't find it, obviously):
HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\9A9192E5849F91945A1B03B88B701A97\InstallProperties
So the key difference being
RTM-- BA2E5E0A5A687F244A67FD7AC4440CC2
Patch- 9A9192E5849F91945A1B03B88B701A97
What forces drive windows installer to look in this path? Is this based on a
stable GUID of some kind that may be changing under the hood that we can't
see?
Thoughts anyone?
-Original Message-
From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca]
Sent: June-09-15 9:04 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Patches no longer working for a specific RTM using WiX
3.7 + Pure WiX Patching
This may be totally off base, so take it with a grain of salt, but:
I seem to remember that MSPs generally share a product code with their parent,
though it drove me crazy trying to figure that sort of thing out. I have now
told my colleagues I don't intent to support them, because they seemed way more
trouble than they are worth. At least for now, all our applications are under
approximately 10 megabytes, and isn't worth it sending pieces. (This may come
back to haunt me later when new applications arrive, because they are
supposedly ~100 megabytes and we may not be able to make bundles that we can
then factor into MSIs for updates.)
Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6
keith.doug...@statcan.gc.ca Telephone | Téléphone 613-854-5589 Facsimile |
Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada
-Original Message-
From: Tunney, Stephen [mailto:stephen.tun...@nuance.com]
Sent: June-08-15 7:57 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Patches no longer working for a specific RTM using WiX
3.7 + Pure WiX Patching
Ok, so from my wixmst I get the following in my _SummaryInformation table
row sectionId=*/* sourceLineNumber=E:\dev\File.wxs*8
field9/field
field{5E2919A9-F948-4919-A5B1-308BB807A179}5.4.23.4809;{269AF2D8-5BA4-4D2C-9C53-27588F1D1A33}5.4.0.0;{CE1F01CC-4894-497F-A743-07DDA34618E0}/field
/row
From my RTM WixPDB xml I have this in the Property table:
row sectionId=*.ProductCode
sourceLineNumber=E:\dev\File.wxs*7
fieldProductCode/field
field{5E2919A9-F948-4919-A5B1-308BB807A179}/field
/row
I hope I'm going in the right direction. Maybe someone has some insights out
there? :)
-Original Message-
From: Tunney, Stephen [mailto:stephen.tun...@nuance.com]
Sent: June-08-15 3:48 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Patches no longer working for a specific RTM using WiX
3.7 + Pure WiX Patching
I have found an article
Re: [WiX-users] Download Msi or Exe with Bundle
The bundle can self-update itself. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Shal Philipp [mailto:luc2...@inbox.ru] Sent: Wednesday, June 10, 2015 3:52 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Download Msi or Exe with Bundle Hello. I'm trying to develop simple scenario - Bootstraper after running download last version of installer and installs it. Am i right that it is impossible for Bundle now? Neither exe installers (hash is necessary in RemotePayload) nor msi installers (msi should be analyzed while build and hash computes too) can't implement such scenario. Do I understand it in a proper way or I'm missing something and in 3.9 we can download and install installers somehow without hash check but only with signature check? Thanks for answer. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Download-Msi-or-Exe-with-Bundle-tp7600586.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Download Msi or Exe with Bundle
Note: patching can be very sensitive so we don't tend to make any guarantees that changing toolset versions (even between minor versions) won't break patching. Major upgrades should always work (even between major versions). _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: Wednesday, June 10, 2015 2:47 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Download Msi or Exe with Bundle The only issue I had, and it was minor, was migrating an extension from WiX 3.5 to WiX 3.6. I have had no issues with migration from WiX 3.6 onwards. -- John Merryweather Cooper Senior Software Engineer | Integration Development Group | Enterprise Notification Service Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |jocoo...@jackhenry.com -Original Message- From: Phill Hogland [mailto:phogl...@rimage.com] Sent: Wednesday, June 10, 2015 4:24 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Download Msi or Exe with Bundle The e-mail below is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. I believe that upgrading a bundle or msi, creating to use wix 3.7 tools, to a later version of wix 3.x as being none-breaking and supported. However the binary compatibility of a wix extension created with one version of 3.x does not extend to a later version of wix 3.x. You need to recompile your binary tools (wix extensions and CAs when dependent on wix) with the wix toolset that you are using. At least that is my understanding and my observation. I have shipped and upgraded bundles/msi created using wix toolsets from 3.7 through 3.10 without issue, but I always have to recompile my wix custom extensions and binary dependencies. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Download-Msi-or-Exe-with-Bundle-tp7600586p7600602.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] per-user per-app WiX installation
Try Packages/@InstallScope instead. It absorbs all those settings. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Carles Pina i Estany [mailto:car...@pina.cat] Sent: Wednesday, June 3, 2015 9:23 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] per-user per-app WiX installation I'm using InstallPrivileges=elevated but I never get the request for the privileges (Windows 7, on a non-admin account, other software request the privileges) On Jun/03/2015, Carles Pina i Estany wrote: TL;DR: How can I make MSI to ask the user for elevated privileges? With the WixUI_Advanced I have the option to install the package per-machine or per-user... so this is a good step. If I could make the MSI package to request for elevated privileges this would maybe be all (if the user grants: installs by default per-machine, if the user doesn't give access per-user). At the moment if it's a standard user the only option is per-user. I just need the MSI to ask for elevated privileges. Regards, On Jun/03/2015, Carles Pina i Estany wrote: Hello, I'm migrating an existing NSIS installer to WiX. I use cpack for the project but I'll take care of the cpack issues. This is a per-user / per-computer flow question. The current NSIS does: -- If the user executing the installer has admin privileges: By default it installs into C:\Program Files\BlaBla (per-computer) (user can change it, but C:\Program Files is the default one) else: Windows shows the dialog to run the program as: ( ) Current User (X) Run the program as the following user: Administrator (by default) If the user selects Current User: -per-user installation, in %APPDATA%\something If the user selects Administrator: -user enters the password -per-computer installation (in C:\Program Files\BlaBla) -- Any pointer what's the easiest way to do this using WiX? I'm experimenting with things like Property Id ALLUSERS and MSIINSTALLERPERUSER but no success yet. More than debugging my attempt I'd like to know if this is possibl to do and some pointer to a more or less recent thing... Thank you! -- Carles Pina i Estany Web: http://pinux.info || Blog: http://pintant.cat GPG Key 0x8CD5C157 -- Carles Pina i Estany Web: http://pinux.info || Blog: http://pintant.cat GPG Key 0x8CD5C157 -- Carles Pina i Estany Web: http://pinux.info || Blog: http://pintant.cat GPG Key 0x8CD5C157 -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Reboot after NetFx451Redist problem
There is a feature request for a RestartBoundary. Not implemented yet. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Martin Evans [mailto:martin.ev...@voyagersoftware.com] Sent: Friday, May 29, 2015 2:39 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Reboot after NetFx451Redist problem I think I've encountered the reboot required scenario covered here http://sourceforge.net/p/wix/bugs/3310/ Various windows services subsequently installed by our MSI fail as the framework seems to need a reboot. Having looked at what's done in \src\ext\NetFxExtension\wixlib\NetFx451.wxs I'm tempted to copy it, remove the /norestart and set the Protocol to None. Yet it feels wrong to take this approach, particularly as NetFx451.wxs appears to be doing the right thing based on this https://msdn.microsoft.com/en-us/library/ee942965(v=VS.110).aspx I'm also worried about successfully continuing after the restart. Does anyone have any suggestion or thoughts on this proposed work-around? Thanks, Martin -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn: how to elevate BA? (Manifest for Burn Bootstrapper [Continue])
Put the registry key in a package in the chain. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Jiri Tomek [mailto:katu...@volny.cz] Sent: Friday, May 29, 2015 6:39 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Burn: how to elevate BA? (Manifest for Burn Bootstrapper [Continue]) This is just wrong. There are valid scenarios when Bootstrapper may need for example to write a registry value. I don't say that it should be default mode but it should be possible to request elevation for whole BS. Burn is really powerful with custom MBA but this limitation just says We know better what you need. If you need elevation you are just crappy developer.. That's not nice. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Failed to extract payloads from container after reboot continuation
Sounds right. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Jiri Tomek [mailto:katu...@volny.cz] Sent: Friday, May 29, 2015 5:19 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Failed to extract payloads from container after reboot continuation I found some more information. The issue does not seem to be caused by NSIS wrapper but by fact that original .exe name is different than what Burn expects. New STR are: - Build BS as setup.exe - Rename BS to installer.exe - Run install from installer.exe - Let .NET prereq be installed - Reboot Now continuation fails with error mentioned in first post Failed to resolve source for file: C:\setup.exe, error: 0x80070002.. If I don't rename setup.exe to installer.exe it works. So it seems that Burn has issues if you rename original built file and install flow contains a reboot. It's probably because generated BurnManifest contains: Container Id=WixAttachedContainer FileSize=83859245 Hash=11D22668B518B8EF8B246BD9298058B88F82790C FilePath=setup.exe ... / and this value is used after reboot. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn: how to elevate BA? (Manifest for Burn Bootstrapper [Continue])
Why custom actions to write registry keys? Why so much complexity? Actually, those are rhetorical questions, I don't really want to know the answers. smile/ You are choosing to work against installation best practices. Best of luck to you. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Jiri Tomek [mailto:katu...@volny.cz] Sent: Friday, May 29, 2015 11:48 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Burn: how to elevate BA? (Manifest for Burn Bootstrapper [Continue]) It's not fixed key. I use bootstrapper to gather various configuration information from user which are then used to configure product and not all of then are passed to MSIs. Adding logic to MSI to be able to get this information via MSI properties, parse it and then store it in registry is just unreasonably complex compared to few lines in .NET code in BS. What I ended up doing is that I detect requirement for elevation in BS and I let BS start itself as elevated process using runas verb. I feel really bad about it but so far that is far more maintainable than pushing logic to MSI custom actions. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Localizing Burn Condition messages
Run time, aka: install time, (#) vs. bind time (!) vs. preprocessor time ($). _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Ryan Waller [mailto:rwal...@microsoft.com] Sent: Wednesday, May 27, 2015 2:06 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Localizing Burn Condition messages It does work. Just had to use the *#*(loc.StringId) instead of the *!*(loc.StringId) syntax for the bal:Condition@Message attribute. The WixStdBA localizes with the # syntax. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Add new packages to install chain dynamically in managed BA
No, definitely not. The security issues have been discussed here in the past. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Jiri Tomek [mailto:katu...@volny.cz] Sent: Tuesday, May 26, 2015 12:10 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Add new packages to install chain dynamically in managed BA Hello, is it possible to add new packages to Burn install chain dynamically from managed BA if these packages were not known during build time? What I'm trying to achieve is to ship a small bootstrapper to users and let this bootstrapper contact my server and get list of packages to install. This list will contain items that did not exist when BS was built so they have no entry in original .wxs files. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Hiding UpgradeCode Attribute Warning
Why do you need a new UpgradeCode all the time? _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Griesshammer, Christoph (GE Healthcare) [mailto:christoph.griessham...@ge.com] Sent: Tuesday, May 26, 2015 10:45 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Hiding UpgradeCode Attribute Warning How do I auto-gen an UpgradeCode? * isn't a valid entry for UpgradeCode. Do I actually need the build process to go in and build a new code? Christoph -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Hiding UpgradeCode Attribute Warning
Yes, I read that. However, that doesn't say why you need a unique UpgradeCode all the time. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Griesshammer, Christoph (GE Healthcare) [mailto:christoph.griessham...@ge.com] Sent: Tuesday, May 26, 2015 11:18 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Hiding UpgradeCode Attribute Warning As I had described in my other emails, I am in a situation where our upgrades are really just an install of another version. They need to exist side-by-side. But I need to remove the warning that is brought up that I don't have an upgrade code, and the upgrade code can't have the * value. Christoph -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Add new packages to install chain dynamically in managed BA
Yes, always update the Bundle. It vouches for the security of everything it contains (hopefully, you sign your bundle). _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Jiri Tomek [mailto:katu...@volny.cz] Sent: Tuesday, May 26, 2015 11:04 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Add new packages to install chain dynamically in managed BA The scenario that I have is that once used downloads bootstrapper it will serve as central point for installing future updates, new packages etc. From what you described I will have to always create new bundle with new packages and then let original BS download it via some kind of autoupdate that I implement. That way user will always get latest bundle with all proper packages defined within. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Hiding UpgradeCode Attribute Warning
Despite its name, UpgradeCode can serve other very useful purposes... like detection. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: David Connet [mailto:d...@agilityrecordbook.com] Sent: Tuesday, May 26, 2015 8:54 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Hiding UpgradeCode Attribute Warning I am WELL aware of the following: 1) You should always have an upgrade code, even if you don't plan on upgrading. But for this specific product, I am positive I do not want the upgrade code. We will never support an upgrade for this product, due to other incredibly obnoxious issues. Haha. Famous last words! :) (Several times we've been absolutely assured that X will _never_ happen. So we base our architecture on that. A time duration=soon/ later, we need to implement X. sigh. We (devs) now architect with the assumption that X will happen.) Seriously, just set the upgrade code. GUIDs are cheap. If you will never upgrade, nothing is lost. But if you do ... major pain averted! Dave -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Hiding UpgradeCode Attribute Warning
This statement is not true: Having the same UpgradeCode for 2 installers causes the installer to initiate an upgrade instead of an additional installation. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Griesshammer, Christoph (GE Healthcare) [mailto:christoph.griessham...@ge.com] Sent: Tuesday, May 26, 2015 11:33 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Hiding UpgradeCode Attribute Warning Having the same UpgradeCode for 2 installers causes the installer to initiate an upgrade instead of an additional installation. I want a new UpgradeCode each build, so that no 2 packages will have the same UpgradeCode, allowing us to install the multiple versions. If there is a better way to do this, I am open to it. Christoph -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Hiding UpgradeCode Attribute Warning
Yeah, ships passing in the night. smile/ ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Griesshammer, Christoph (GE Healthcare) [mailto:christoph.griessham...@ge.com] Sent: Tuesday, May 26, 2015 12:07 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Hiding UpgradeCode Attribute Warning You can see my latest email. I thought about that after I emailed it, and tested it out. I realize now you need the MajorUpgrade element for it to work. Thank you for your help (everyone who responded), Christoph -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn failed to initialize COM at EngineRun().
File the bug. Burn (the engine) should never crash. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Uni Gauldoth [mailto:unigauld...@gmail.com] Sent: Tuesday, May 26, 2015 9:37 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Burn failed to initialize COM at EngineRun(). Hi, I've found the culprit. I installed a program named Lingoes(a translator), and run the Ligoes.exe in the back. When my installer starts, it loaded the following dll before entering stub.exe's wWinMain. C:\Users\Administrator\AppData\Local\Lingoes\Translator\lingoes-us\OpenText32.dll It looks like this OpenText32.dll already initialized COM using a different thread mode. If I terminate the Ligoes.exe, the problem vanished. Since I'm using debug version of burn.exe, it will crash. In release version of burn.exe, it will not crash because ExitOnFailure is not available under release build. So is this a bug? Or a flaw I can just ignore? Regards, Gauldoth -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Hiding UpgradeCode Attribute Warning
Don't add a MajorUpgrade element. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Griesshammer, Christoph (GE Healthcare) [mailto:christoph.griessham...@ge.com] Sent: Tuesday, May 26, 2015 9:24 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Hiding UpgradeCode Attribute Warning I'm understanding now that I can use the MajorUpgrade element while providing a UpgradeCode to achieve what I need. I'm just not sure from the documentation yet. What attributes do I need to include for the MajorUpgrade element? I looked at the documentation and it isn't immediately clear to me. I need to still allow multiple versions of the product to be installed. They'll have the same GUIDs, though, since we can't automatically generate the GUIDs every build for the UpgradeCode. So if I say Disallow=yes for MajorUpgrade, will I still be able to have multiple versions installed? Christoph -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix Built-in Variable escape content
See if BAfunctions in wixstdba can get you what you want. If not, would need to create a new BA. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Tucaliuc Mihai . [mailto:tucaliucmi...@gmail.com] Sent: Wednesday, May 20, 2015 7:55 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Wix Built-in Variable escape content And it this case, how could I escape the values by hand? I was trying to create my own Bootstraper but i cannot use .NET for it since in production it may not be installed on every machine. Also I downloaded the source code for wixstdba with the attempt to modify it :D but I didn't get to far with that. What would your suggestion be? -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] .NET Prerequisite, Burn, and the ARP
IIRC, Burn should keep registration in ARP when the first non-permanent package is installed (aka: there is something Burn would do). A RollbackBoundary after the permanent packages *may* be necessary but my memory is fuzzy there. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Colin Sim [mailto:colin@ipfx.com] Sent: Wednesday, May 20, 2015 11:48 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] .NET Prerequisite, Burn, and the ARP Phil: there's absolutely no need to apologise. All forum users (I know I am) appreciate your input and time spent helping out on the forum. I'll need to look into this issue anyway as part of a project of mine (which I'll get back to soon I hope). I'll report back anything meaningful that I find. I'll certainly give your suggestion, regarding the use of a dummy package ago. If it works though, it still feels like a hack as opposed to a proper solution to me. I haven't looked through the Burn engine code, but from my experience of using Burn to date (granted not very long) - it feels like at some earlier point in development, it was easier to piggy back of the bundle chain to support the runtime environment for the bootstrapper as opposed to having a clean and separate concept for prerequisite(s) specifically for the bootstrapper itself. Could any of the developers comment or share their insight into the design intent that has resulting in what we're seeing now? -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Writing a dual-purpose managed bootstrapper
Burn doesn't support MSIs that switch install scope today. You'll have to pick one at build time. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Jeff Tyson [mailto:jeff.ty...@microsoft.com] Sent: Thursday, May 14, 2015 11:00 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Writing a dual-purpose managed bootstrapper Hello, I am trying to build a managed bootstrapper that can install as both per-user and per-machine. In the dual-purpose MSI I set the package scope to perUser: Package InstallScope=perUser / In the bundle I have MsiPackage SourceFile=Installer.msi MsiProperty Name=ALLUSERS Value=2 / MsiProperty Name=MSIINSTALLPERUSER Value=[MsiInstallPerUser] / /MsiPackage Finally in the managed bootstrapper, if the user is an administrator, I set the MSI as per-machine Engine.StringVariables[MsiInstallPerUser] = ; Otherwise, I set the MSI to per-user Engine.StringVariables[MsiInstallPerUser] = 1; Everything works fine when I install a per-user bundle, however when I try to install per-machine I never get the UAC prompt. Is burn designed to do this or am I doing something wrong? Thanks, Jeff Tyson -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Error 2911: Could not remove the folder C:\Config.Msi\.
Sounds like a Windows Installer problem. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Miroslav Rodic [mailto:rod...@arco011.com] Sent: Saturday, May 16, 2015 2:56 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Error 2911: Could not remove the folder C:\Config.Msi\. I think that I succeeded to localize the issue, but I can not find the solution. I forgot to say what I succeeded to localize. When there is a File element in the msi package then error message is displayed. If there is no File element at all, then the light complains that msi package is without any file (warning LGHT1079 : The cabinet 'afile.cab' does not contain any files...), but uninstall log of such a package does not contain the above mentioned error message. Regards, Miroslav -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix and FinalBuilder - InvalidOperationException: Collection was modified; enumeration operation may not execute [SEC=UNOFFICIAL]
Always possible. There's a probably a couple 100,000 lines of code in the WiX toolset. Dropping .pdbs next to the tools and getting the resulting call stack would narrow it down to which line of code is offending. Plus, knowing which version of the WiX toolset would help too since the code keeps changing with each build. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Scott Brown [mailto:scott.br...@aec.gov.au] Sent: Tuesday, May 19, 2015 1:06 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Wix and FinalBuilder - InvalidOperationException: Collection was modified; enumeration operation may not execute [SEC=UNOFFICIAL] UNOFFICIAL Hi Wix Users While running a build in FinalBuilder, when it gets up to the Wix installer project and runs the linker light.exe, I get the following error InvalidOperationException: Collection was modified; enumeration operation may not execute. Does anyone know what could cause this? This error is supposed to occur when adding or removing items while looping over a collection. Does light.exe do this? Regards Scott Brown -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix Built-in Variable escape content
I guess Burn is resolving the variables in the InstallCommand multiple times. Not sure there is a work around except to escape the values by hand. Probably a reasonable thing to file a bug on but fixing it may be hard since it'd likely be breaking behavior change. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Tucaliuc Mihai . [mailto:tucaliucmi...@gmail.com] Sent: Tuesday, May 12, 2015 8:30 AM To: wix-users Subject: [WiX-users] Wix Built-in Variable escape content Hello, I'm trying to use the Built-in variable WixBundleOriginalSource in order to send to an executable package the source path from where the bundle originally ran. This is my code ExePackage Id=InstallConditions SourceFile=..\Bin\$(var.Configuration)\MyPackage.exe Vital=yes InstallCommand='[WixBundleOriginalSource] [SqlServer] [DatabaseName]' Permanent=yes ExitCode Value=0 Behavior=success/ ExitCode Behavior=error/ /ExePackage The problem is that if the source path contains square brackets the content of them will be deleted. For example lets say that i'm trying to execute the installer from location C:/MyTestFolder/Some[Missing]Data/Install.exe. The WixBundleOriginalSource variable will return to my executable package the following location C:/MyTestFolder/SomeData/Install.exe, without the [Missing] text. Do you have any idea how can I escape the value from this built-in variable? Thanks, MihaiT -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn does not show close application warning during uninstall
I guess I'd expect if the util:CloseApplication is sending an ::MsiProcessMessage() that wixstdba would show it. Would need to look closely at the code. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: roberthyang [mailto:robert_y...@agilent.com] Sent: Thursday, May 14, 2015 11:24 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Burn does not show close application warning during uninstall Hi all -- dumb question here. I've noticed that util:CloseApplication works within an MSI, but when that MSI is used within a bundle, we are simply prompted to reboot instead of the nice prompt. Is there a cheap dirty way to get the MSI-only behavior in the bundle without writing our own bootstrapper application ? We're using the stdba and Wix 3.9r2 right now. We're targeting Windows 7 only and a custom action isn't out of the question, but am curious to know if someone has already solved this problem before I start coding (smile). Thanks ! -Rob -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Need help with uninstall
Did you use MSIENFORCEUPGRADECOMPONENTRULES? http://robmensching.com/blog/posts/2007/1/4/doing-a-small-update-or-minor-upgrade-in-msi-use/ _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: victorwhiskey [mailto:victorhwhis...@yahoo.com] Sent: Monday, May 18, 2015 8:55 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Need help with uninstall Hello all, I'm having trouble with uninstalling my product after I do a minor upgrade. So I test with installing my program and then uninstalling the program and that works fine. Then the next test is install the program (v.1.0.0.x) then do a minor upgrade (upgrade to v.1.0.2.y). That works fine. Next I try to uninstall the program. Here's where I run into my problem. The program gets removed from ARP making it seem like it's uninstalled, however, all directories and files still exist after the uninstall. I've compared the logs and the difference I see is when it lists the components and their states, in the good log it says ...Request: Absent; Action: Absent signifying a remove. However in the bad log it says Request: Null, Action: Null signifying no action. The Product.wxs contains. ... Product Id=$(var.ProductCode) Name=$(var.ProductName) Language=1033 Version=!(bind.FileVersion.fil12413D1AEB784C72BBAD4277614C2F22) Manufacturer=$(var.Manufacturer) UpgradeCode=$(var.UpgradeCode) ... MajorUpgrade AllowDowngrades=no AllowSameVersionUpgrades=yes Disallow=no DowngradeErrorMessage=A newer version of [ProductName] is already installed. IgnoreRemoveFailure=no MigrateFeatures=yes Schedule=afterInstallInitialize/ ... I'm running this from a bundle using wix3.8 and will try to attach the logs. Any help appreciated! Thanks good.log http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/file/n7600353/good.log bad.log http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/file/n7600353/bad.log -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix installer with modern ui look
Make a bundle: http://robmensching.com/blog/posts/2012/6/25/b-is-for-bundle-and-thats-good-enough-for-me/ _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Gareth Price [mailto:gar...@genpoint.co.za] Sent: Tuesday, May 12, 2015 11:51 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Wix installer with modern ui look Hi All My question is simple, how can I give my wix installer a modern ui look and feel? Im using wix edit to build my dialogs, is there a plug in or extension I can install to provide this ability ? Thanks! -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Warning condition in Standard BA
wixstdba does not have support for that today. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Rajesh Nagpal (SQL) [mailto:rnag...@microsoft.com] Sent: Tuesday, May 12, 2015 4:38 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Warning condition in Standard BA Hello All, I've started working on the Wix Burn installer(on Wix 3.8) and have been loving it so far! I had a quick question: Is there a way to add a non-blocking condition(warning) using the Standard BA to warn the user of any condition but not necessarily block him from proceeding further. I see that the bal:Condition element fails the setup if the condition is false. Regards, Rajesh -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Per-User Previlage To Write to Program Files
In this case, a verbose log file would be more useful. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Scott Ferguson [mailto:scott.fergu...@a2ktechnologies.co.nz] Sent: Monday, May 11, 2015 12:21 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Per-User Previlage To Write to Program Files Not sure about the internal filters that might be set and I wouldn't know what to look for using Orca to view the .msi file to see what might be allowing me to install to Program Files in a per-user install. I do know it is installing to Program Files and not Program Data. If you are curious and wanted to have a look I have created a simple test app and an InstallShield LE installer where the ALLUSERS switch is set to per-user and the data installs to Program Files. The resulting .msi file is in the top level of the zip. I have zipped them and placed them in dropbox if you wanted to download. This is a x64 installer.: https://www.dropbox.com/s/f78ijq0z8qpuwn3/Test%20Project.zip?dl=0 -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Per-User Previlage To Write to Program Files
Maybe it's the app compat filter driver redirecting you to ProgramData and you're not actually in ProgramFilesFolder. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Scott Ferguson [mailto:scott.fergu...@a2ktechnologies.co.nz] Sent: Sunday, May 10, 2015 1:44 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Per-User Previlage To Write to Program Files Sorry for the late response. Yes I have successfully installed to Win7 and Win8 without having to make any changes to the installer. Kind regards Scott Ferguson -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is Windows Path namespace \\?\ supported by MSI/WiX as a target location
The Windows Installer does not and the .NET Framework does not. So nothing in the WiX toolset does because it wouldn't work even if we did. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Phill Hogland [mailto:phogl...@rimage.com] Sent: Saturday, May 9, 2015 11:59 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Is Windows Path namespace \\?\ supported by MSI/WiX as a target location Does anyone know if MSI (and by extension WiX) supports the use of the extended-length' prefix (\\?\) on folder paths, such as for a directory property: INSTALLATIONFOLDER=\\?\D:\somereally_long_name\or_string_of_long_folder_names_of_32,767 characters\ The MSDN document here https://www.google.com/webhp?sourceid=chrome-instantion=1espv=2ie=UTF-8#q=Windows+Installer+%5C%5C%3F%5C+prefix+to+paths describes using an 'extended-length path, use the \\?\ prefix. For example, \\?\D:\very long path.' I looked in the Windows SDK and did not find an answer. (And by extension if it is supported in MSI, does Burn support the use of prefixed really long paths (32,767 characters) in Burn variables to drive a MSI property?) Thanks; Phill -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] (Burn) question about not upgrading a MSI
Custom BA could set the RequestState on the package correctly and avoid all the issues you describe. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Patrice Bastien [mailto:patr...@icam.com] Sent: Friday, May 8, 2015 12:57 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] (Burn) question about not upgrading a MSI Hello, I am using burn at the moment to install 2 separate MSI files which I set to visible so I end up with 3 ARP entries which is fine with me. My burn UI have a checkbox which allow me not to install the second MSI if I do not want to upgrade that one. For this, I did not use InstallCondition because I do not want it to also uninstall. So I pass the check box value as a property to the MSI which will exit successfully early on (WixExitEarlyWithSuccess custom action). The only problem I have left is that when installing an upgrade of the bundle and not upgrading that second MSI, it is still uninstalled by the automatic removing of the previous bundle. Is there anyway I can prevent this from happening? If I use permanent=yes on the MsiPackage, that could be fine but I still want the bundle to uninstall it if the user explicitly uninstall the bundle manually. Thanks, Pat -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Modifying new msi package prior to recache in a custom action
Yeah, stop the madness. Admit a mistake was made and ship mandatory updates to A, B and the already released C's via some other mechanism (Burn bundle?). Then get on to a good path with the new C. Don't bring down your future by trying to dig a deeper custom action hole. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Edwin Castro [mailto:egca...@gmail.com] Sent: Wednesday, May 6, 2015 11:13 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Modifying new msi package prior to recache in a custom action I'll provide more details. I inherited the installer codebase for a product that has released twice (A, B) and was almost ready to release again (C). Releases A and B have poorly written custom actions that cause them to fail occasionally (say 5% of the time) while they are getting uninstalled as part of an upgrade to a newer version (C). We want to fix these issues in C and deliver it as a replacement for A and B during an upgrade. Our original plan was to build C three times. First build would have Release A's ProductCode and ProductVersion (let's call it A' ). Second build would have Release B's ProductCode and ProductVersion (let's call it B' ). Third build would have a new ProductCode and ProductVersion for Release C (let's call this C' ). C' would have A' and B' in the Binary table and we wrote an immediate custom action to extract and recache A' or B' when upgrading from A or B. The we realized that we need to fix pre-releases for C (lets call them C* because there are many). We determined our original plan does not scale well as we'd need a C' for each C* pre-release. The only difference between A', B', and all C' packages would be ProductCode and ProductVersion. Thus we want to build a single C' package to include in the Binary table. In our custom action we want to extract that single C' package to disk, modify the package's ProductCode and ProductVersion to what is currently installed, and recache the package. After I have extracted the C' package to disk I try the following set of calls (error handling omitted): PMSIHANDLE hDatabase = NULL; WcaLog(After previous function call); WcaLog(Before MsiOpenDatabase(%ls), wzFileName); er = MsiOpenDatabase(wzFileName, MSIDBOPEN_DIRECT, hDatabase); WcaLog(After MsiOpenDatabase); The behavior I see in the log is RecacheExistingProduct: After previous function call MSI (s) (D4:84) [14:23:56:565]: Leaked MSIHANDLE (71) of type 790541 for thread 1380 MSI (s) (D4:84) [14:23:56:565]: Note: 1: 2769 2: RecacheExistingProduct 3: 1 MSI (s) (D4:84) [14:23:56:565]: Note: 1: 2205 2: 3: Error MSI (s) (D4:84) [14:23:56:565]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 2769 RecacheExistingProduct: Before MsiOpenDatabase(path\to\C'\package\on\disk) FYI, I also tried MSIDBOPEN_TRANSACT but saw no difference in the log. The wzFileName variable contains the path to the C' package I just extracted from the Binary table. I read online that type 790541 indicates a database MSIHANDLE is getting leaked. I expected that if MsiOpenDatabase was returning an error that was causing my custom action to exit early, then I would see log messages in the cleanup code but those log messages do not show up. Instead the last message that shows up in the log is the message logged BEFORE MsiOpenDatabase is called AND that message appears after MSI logged the leaked MSIHANDLE. To me this seems to indicate something similar to a SEGFAULT occurred causing the immediate termination of the custom action. The MSDN documentation on MsiOpenDatabase at https://msdn.microsoft.com/en-us/library/aa370338.aspx says Because MsiOpenDatabase initiates database access, it cannot be used with a running installation. Based on the behavior I see in the log I'm interpreting the quote above to mean that I cannot call MsiOpenDatabase in a custom action because custom actions execute within a running installation. I'm looking for confirmation that my interpretation above is correct. I'm having a hard time explaining why I don't see any of the error handling code logging as I expect it to do. I was already using PMSIHANDLE and I know that wzFileName has valid content because the Before MsiOpenDatabase message contains the correct path information. I think my only option is to move this custom action into it's own executable so it is not executing in a running installation. Is this correct? -- Edwin G. Castro -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight.
Re: [WiX-users] specifying an installed executable to be run at boot time
Or run it from the per-machine Run key to be elevated. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Nir Bar [mailto:nir@panel-sw.com] Sent: Thursday, May 7, 2015 12:43 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] specifying an installed executable to be run at boot time Running an executable at boot can be done with the registry Run key https://msdn.microsoft.com/en-us/library/windows/desktop/aa376977(v=vs.85).aspx . If you need it to run with elevation you can run it as a Windows service http://wixtoolset.org/documentation/manual/v3/xsd/wix/serviceinstall.html with local system account. - Nir Bar Freelance Developer Mail: nir@panel-sw.com Web: www.panel-sw.com - C++ On Windows, Linux and Embedded Platforms - WiX InstallShield -- -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Per-User Previlage To Write to Program Files
You have to be elevated to install to ProgramFiles. Your per-user MSI never should have been able to install to ProgramFiles unless you always launched it from an elevated process. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Scott Ferguson [mailto:scott.fergu...@a2ktechnologies.co.nz] Sent: Thursday, May 7, 2015 2:55 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Per-User Previlage To Write to Program Files Hi, I am using Wix 3.9.1208. I have an installer created earlier with Install Shield Limited Edition that installed as a per user package. I have been upgrading the original installation over the last two years. I now need to upgrade the program using Wix as I need the additional functionality Wix provides. The issue I am having is when I use Wix as the installer and I have the InstallScope attribute set to per-user I get an error message that says the installer has insufficient privileges to access this directory and the message is pointing to the Program Files/My Application directory. I have done quite a bit of research on this over the last two days and I believe this issue has been brought up several times e.g. http://sourceforge.net/p/wix/mailman/search/?q=per-user+Program+Files+insufficient+privilege The answer seems to be to be either move the installation away from Program Files or to elevate the InstallScope attribute to perMachine. I can confirm that perMachine does fix the privileges issue but it is not a viable solution for me in this instance. Neither of those two options will work for me. 1) I cannot change the InstallScope attribute as I am creating an update so the InstallScope between the two versions need to be the same or it will install side-by-side instead of updating. 2) To change the location of the install directory means changes to settings and possibly the source code (I won't know until I test)! Does anyone know of a solution that will allow me to do a per-user install to Program Files? Kind regards Scott Ferguson -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] util:User not being removed on uninstall
What did the log file say? _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Cockerham, Gregory [mailto:gregory.cocker...@siemens.com] Sent: Wednesday, May 6, 2015 8:29 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] util:User not being removed on uninstall I am creating a user during my install and adding that user to the Administrators group: Component Id=cmpId Guid=guid Win64=yes KeyPath=yes CreateFolder/ util:User Id=systemAdmin CreateUser=yes RemoveOnUninstall=yes FailIfExists=no Name=[SERVICEACCOUNT] Password=[SERVICEACCOUNTPWD] CanNotChangePassword=yes PasswordNeverExpires=yes UpdateIfExists=no util:GroupRef Id=AdminGroup/ /util:User /Component The user is not being removed on uninstall. It was working and I haven't changed this code in a while (if ever). The only difference I'm aware of between when it was working and now is we upgraded from Wix 3.8 to 3.9. Any help appreciated. -Greg This message and any attachments are solely for the use of intended recipients. The information contained herein may include trade secrets, protected health or personal information, privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you are not an intended recipient, you are hereby notified that you received this email in error, and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. Thank you for your cooperation -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] No reboot for locked files during uninstallation.
Why do you want to force a restart? Your application is safely gone. Those files will be cleaned up whenever the users chooses to restart again. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Akshat Goel [mailto:aksg...@adobe.com] Sent: Tuesday, May 5, 2015 5:03 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] No reboot for locked files during uninstallation. Hi, Our product installs DLLs as part of installation. Most of the DLLs are used by our application but couple of these are also used by other processes and applications. When we uninstall the product, our main application is closed and DLLs are freed. However, other processes may still be running and thus, some DLLs may be locked. During uninstallation, Windows installer copies these files to C:\Config.msi. When uninstallation completes, there is no message for reboot or cleanup. However MSI log shows the entry Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\3f6c9d1.rbf. Must reboot to complete operation. My problem is how to show the user that a reboot is required to cleanup the files. Currently uninstallation finish screen doesn't show any message that a reboot maybe required. I have a sample package which demonstrates the issue, if anyone needs. Thanks hoping for a reply. Regards, Akshat -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ExecSecureObjects: Error 0x80070005 - failed to get security info for object
ERROR_ACCESS_DENIED. Permissions are such that not even the Windows Installer can access the file. SYSTEM removed? _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Mohamed Yasir [mailto:yasirmohame...@gmail.com] Sent: Monday, May 4, 2015 9:14 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] ExecSecureObjects: Error 0x80070005 - failed to get security info for object Hi, I have seen this in my MSI log files but not really sure what this means: MSI (s) (A8:C8) [08:52:32:880]: Hello, I'm your 32bit Elevated custom action server. ExecSecureObjects: Error 0x80070005: failed to get security info for object: \\GBBED01FI01\HOME01\GBCO0101\My Documents\Visual Studio 2010\Templates\ProjectTemplates\Visual C#\ CustomAction ExecSecureObjects returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Regards, Mohamed Yasir K -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ExecSecureObjects: Error 0x80070005 - failed to get security info for object
Hah, missed the network share thing. Doh! That's probably it. Machine will need access. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Sent: Tuesday, May 5, 2015 10:43 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] ExecSecureObjects: Error 0x80070005 - failed to get security info for object Seems relevant http://stackoverflow.com/questions/28588729/wix-msi-fails-when-setting-permissions-on-network-path-utilpermissionex -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] File not getting overwritten
Created and modified time stamp on non-versioned file different? _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Pavan Konduru [mailto:pavan.kond...@accelrys.com] Sent: Tuesday, May 5, 2015 10:54 AM To: General discussion about the WiX toolset. (wix-users@lists.sourceforge.net) Subject: [WiX-users] File not getting overwritten Hi All, We have an installer that basically is trying to overwrite some files that is on the host system. The files that are being overwritten were not installed by the installer. When I run my installer, all these files get overwritten. On one particular machine, these files don't seem to be overwritten no matter what. Here is a log entry for one of the files. File: C:\Program Files\xxx \lib\xxx.jar; Won't Overwrite; Won't patch; Existing file is unversioned but modified All the other machines where I have run the installer this is the log, where it gets overwritten: File: C:\Program Files \xx \lib\xxx.jar; Overwrite; Won't patch; Existing file is unversioned and unmodified - hash doesn't match source file As per the MSI policy for overwriting files if they don't have versions is to check for the modified dates. The file on system has a 2014 date and the file from the installer has a 2015 date. The hashes don't match as the file content has changed. So, why is the file not being replaced? --Pavan This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged. If you are not one of the named recipients or have received this email in error, (i) you should not read, disclose, or copy it, (ii) please notify sender of your receipt by reply email and delete this email and all attachments, (iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email. For other languages, go to http://www.3ds.com/terms/email-disclaimer -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Detect condition for a Burn Package ?
IIRC, there is a feature request open for that.
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: Marco Tognacci [mailto:mark...@live.it]
Sent: Tuesday, April 28, 2015 1:55 PM
To: WiX - users
Subject: [WiX-users] Detect condition for a Burn Package ?
I have a Burn package (setup1.exe) that have an UpgradeCode={GUID}I have used
this exe package inside another Burn setup (setup2.exe), in this package I need
to get the DetectCondition for the firt package (setup1.exe) is there any way
to get this condition?
util:ProductSearch UpgradeCode=---X
Variable=Setup1_Installed Result=state/ I have tried this but it report
Setup1_Installed = 2 as not installed even if it is really installed,I have
read that this ProductSearch is only for the msi package, is right?
I have search on the registry the UpgradeCode and it appear in the Uninstall
section in a variable BundleUpgradeCode, But I don't know how to check it as it
is under a GUID code that is auto genrated during setup of the setup1.exe Any
way for doing this?Thanks
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Major upgrade: a few files are not installed
Windows Installer only ignores the 4th digit of the MSI version. It'll evaluate all four places of a file version. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Lukas Rieger [mailto:lrie...@nemetschek-engineering.at] Sent: Friday, April 24, 2015 10:59 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Major upgrade: a few files are not installed I opened up both MSIs in Orca and compared their version numbers. The missing files are different, but their version only differs in the forth place (which is ignored by MSI). The fourth place of the upgrading files is actually higher, so there are no higher version components on disk. Files which are exactly the same (same hash and of course same version number) do exist on disk after the upgrade. Files whose version differs in the first three places are also correctly replaced. The affected DLLs are kind of like third party - they are built internally, but the version number is defined by the incremental build and I have no way to change the versioning algorithm (different team, ...). I have also googled some more, and one option seems to be to schedule RemoveExistingProducts even earlier, before costing. Would there be any downside to that? Sorry to take so long to follow up and thank you, Lukas -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Major upgrade: a few files are not installed
No problem. This is what we do for our customers every day at FireGiant
(although FireGiant answers are far more detailed than the 1-2 sentences I have
time to write here).
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: Lukas Rieger [mailto:lrie...@nemetschek-engineering.at]
Sent: Friday, April 24, 2015 11:33 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Major upgrade: a few files are not installed
I thought it treated files like MSIs and only compared the first three digits,
so I glanced over the version number. Comparing them again, OLD NEW.
File Table |File| Component_
| FileName| FileSize | Version
---|
---|
---|
old MSI|fileEcMWtDjRdBXxvVHY.WvW_XXJI4GZcq5iAszC_F3KIwk |
Cj9pc73bMjDSVVGUqS81_nPSltSFuUEweshtzct2AHi4 | bftlang.dll | 118784 |
2004.553.4453.1067
new MSI|fileYXlC3cFPRwh6qrJ5u..Ll052XUiMylAmA6a4BwMlz_o |
CZJsalkL4nX.r6JS5xXH3pjmr9mY1AO4CITmUEHjP82I | bftlang.dll | 118784 |
2004.553.4453.1064
Component Table |Component|
ComponentId| KeyPath
|---
|---
|-
old MSI |Cj9pc73bMjDSVVGUqS81_nPSltSFuUEweshtzct2AHi4 |
{C45097D5-E359-48B5-9F85-AB5EC81D62BF} |
filepcu3NI3UMnsXucCthGSqTSHMvUoyVuyQHRbEXnUVii0
new MSI |CZJsalkL4nX.r6JS5xXH3pjmr9mY1AO4CITmUEHjP82I |
{8B97BC16-7D4D-45CD-A3E3-903C60868202} |
fileYXlC3cFPRwh6qrJ5u..Ll052XUiMylAmA6a4BwMlz_o
MSI (s) (88:A0) [20:12:50:115]: Disallowing installation of component:
{8B97BC16-7D4D-45CD-A3E3-903C60868202} since the same component with higher
versioned keyfile exists
Now that log entry finally makes sense...
*head-table*
Thank you!
So I guess the question becomes how to best downgrade a file during a major
upgrade...
We have no shared components or merge modules, so we always want to put exactly
the version in the msi on disk, even if that means downgrading.
At least according to this (
http://stackoverflow.com/questions/4227456/windows-installer-deletes-versioned-file-during-product-upgrade-instead-of-down?rq=1
) post, scheduling before Costing should work, so I will try that.
Thank you again,
Lukas
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Downgrading a Bundle ?
A BA (native or managed) could be implemented to support downgrades. As I would guess, wixstdba does not (normally it'd be a very surprising and bad thing). _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Martin Cornelius [mailto:martin.cornel...@datron.de] Sent: Wednesday, April 22, 2015 5:40 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Downgrading a Bundle ? Rob Mensching-7 wrote I would be surprised if wixstdba supported downgrades but Burn does. Did your test below use wixstdba? Hi Rob, my Test indeed uses wixstdba, in particular : BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.RtfLicense bal:WixStandardBootstrapperApplication LogoFile=CustomLogo.png LicenseFile=CustomEula.rtf / /BootstrapperApplicationRef Do you say that a custom Installer using ManagedBootstrapperApplicationHost would not suffer this limitation, and thus could support downgrades ? -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] R: WiX Burn use UILevel from simple UI
Integrate what? It's an unimplemented feature request. There is nothing to integrate until someone designs then implements the feature. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Marco Tognacci [mailto:mark...@live.it] Sent: Tuesday, April 21, 2015 11:26 PM To: General discussion about the WiX toolset. Subject: [WiX-users] R: WiX Burn use UILevel from simple UI Yes this is the same issue that I found, is there any plan for integrating it??? Inviata dal mio Windows Phone -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can you replace a MSI in a Burn/Bootstrapper package?
Nope. Hashing, yo! _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Steve-Ogilvie [mailto:steven.ogil...@titus.com] Sent: Tuesday, April 21, 2015 1:22 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Can you replace a MSI in a Burn/Bootstrapper package? Hi folks, Just a quick question I think I know the answer but I want to make sure... Here is what I have done... Did a build in the morning which created my products MSI's. Created an uncompressed Bootstrapper project that has the EXE and RedistSuite folder with all my product (multiple component MSI's) MSI's and pre requisite installers. Later in the day only updated 1 component MSI... Replaced the older MSI with the newer MSI without rebuilding the Bootstrapper. Is that kosher? Thanks, Steve -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bootstrapper Exe Display Security Warning Dialog (Unknown Publisher)
Sign the bundle? http://wixtoolset.org/documentation/manual/v3/overview/insignia.html _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Mrugesh Patel [mailto:mrugesh.pa...@tatvasoft.com] Sent: Tuesday, April 21, 2015 9:53 PM To: General discussion about the WiX toolset. Subject: [WiX-users] Bootstrapper Exe Display Security Warning Dialog (Unknown Publisher) Hello All, When I run bootstrapper exe it display “Open File – Security Warning” dialog with unknown publisher. Can any one help me, “how to change publisher and remove security warning dialog when execute Bootstrapper exe?” ? Thanks, Mrugesh -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Downgrading a Bundle ?
I would be surprised if wixstdba supported downgrades but Burn does. Did your test below use wixstdba? -Original Message- From: Martin Cornelius [mailto:martin.cornel...@datron.de] Sent: Monday, April 20, 2015 07:52 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Downgrading a Bundle ? @Rob : I don't know why it doesn't work, but i made some experiments and can confirm THAT it doesn't work in 3.9R2. : If i try to downgrade a bundle, a message pops up telling that a higher version of the bundle is already installed, which I first have to uninstall. However, having read some discussions and reasoning myself a bit about this issue, i think that this behaviour is 'works as designed' and is not too bad. By default, you also cannot downgrade a 'plain' MSI, and there are some good reasons for this default behaviour, as i learned meanwhile. You CAN build a down gradable MSI (MajorUpgrade AllowDowngrades=yes), but this always raises an ICE warning. If a bundle containing a chain of MSIs allowed downgrading, this could in generally only work reliably if all contained MSIs were also downgradeable. If some of them were not, the downgrade of the bundle would work under certain conditions, and sometimes fail - could be quite confusing to the end user. On the other hand, if an end user desperately has to downgrade, with the current implementation she has the option to first uninstall the bundle (as advised in the error message), and then reinstall the old version. From my point of view, that's sufficient and pretty clear. -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Could not harvest data from a 64bit dll
I think it's an open feature request not a bug. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: ssmsam [mailto:ssmcs...@gmail.com] Sent: Friday, April 17, 2015 10:33 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Could not harvest data from a 64bit dll I am also facing the same issue in 3.9 RC2. Still the bug exists. What would be the workaround fr this? Regards, Sampat -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Downgrading a Bundle ?
Why doesn't that work today? _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Martin Cornelius [mailto:martin-cornel...@t-online.de] Sent: Friday, April 17, 2015 12:54 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Downgrading a Bundle ? I know this has been asked before (and answered as 'impossible'), but perhaps something has changed during the last 6 months ? We're envisioning to create an Installer that uses Burn - for two reasons: - we'd like to check for prerequisites and install them automatically - we'd like to implement a polished UI - leveraging existing WPF skills of our developers However, from the documentation (means : the PACKT book and this list), I conclude that Burn does not support a DOWNGRADE of the installed bundle version. An example to make clear what I mean: - The end user installs a bundle with version 1.0, (which contains an MSI with version 1.0) - The end user upgrades to bundle version 2.0, (which contains an MSI with version 1.1) - The end user detects (after a while) that something is no longer working, thus she needs to go back to version 1.0 (of the bundle, of Course, she doesn't' even know there is an embedded MSI in the bundle). This scenario is a really crucial requirement in our case. AFAIK, this is not possible with bundles - To gain DOWNGRADE capability, we have to resort to 'plain' WiX/MSI (without Burn). Is this really true - and if so, are there any plans to change this in the near future ? Kid regards, Maretin -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Major upgrade: a few files are not installed
You should root cause why higher version Components exist on the machine since you scheduled upgrade early. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Lukas Rieger [mailto:lrie...@nemetschek-engineering.at] Sent: Monday, April 13, 2015 2:29 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Major upgrade: a few files are not installed Sorry, I forgot to mention that I am using Burn as Bootstrapper, so I can't control the REINSTALLMODE Thank you, Lukas -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn and chaining multiple MSIs and detecting proper states for each MSI
Hmm, now I'm confused. What is the issue now? You can certainly override the default planning of packages in your chain via your BA. Not clear how that solves the original issue. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: victorwhiskey [mailto:victorhwhis...@yahoo.com] Sent: Monday, April 13, 2015 9:24 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Burn and chaining multiple MSIs and detecting proper states for each MSI I'm not sure either. Just gasping... Can I manually check for Version numbers and such to determine if I should upgrade or not in the BA? Maybe from DetectPackageComplete? -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How can I prevent Bundle from overriding MSI Upgrade Code?
Note: keeping the source around to minimize source resolution issues is one of the most broken things about fire-and-forget bootstrappers. Burn solves this by maintaining a presence in ARP. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Rob Mensching [mailto:r...@firegiant.com] Sent: Monday, April 13, 2015 8:59 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] How can I prevent Bundle from overriding MSI Upgrade Code? Not today: http://robmensching.com/blog/posts/2012/6/25/b-is-for-bundle-and-thats-good-enough-for-me/ _ Short replies here. Complete answers over there: http://www.firegiant.com/ -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How can I prevent Bundle from overriding MSI Upgrade Code?
Not today: http://robmensching.com/blog/posts/2012/6/25/b-is-for-bundle-and-thats-good-enough-for-me/ _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: ben.lemond [mailto:ben.lem...@matrixteam.com] Sent: Monday, April 13, 2015 7:47 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How can I prevent Bundle from overriding MSI Upgrade Code? Is there a feature that allows you to chain multiple installations (say .net framework and an msi) in one installer but does not create a bundle product. It would be the equivalent of a script that installs multiple pieces and those pieces are the only things that remain. Thanks, [Description: Description: Description: Description: Matrix_Logo_LoRes]Ben Lemond | Software Engineer Office: 812.858.8040 | Cell: 812.205.8585 3299 Tower Drive | Newburgh, IN 47630 ben.lem...@matrixteam.commailto:ben.lem...@matrixteam.com | www.MatrixTeam.comhttp://www.matrixteam.com/ -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn and chaining multiple MSIs and detecting proper states for each MSI
Not clear to me how that would help. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: victorwhiskey [mailto:victorhwhis...@yahoo.com] Sent: Monday, April 13, 2015 8:29 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Burn and chaining multiple MSIs and detecting proper states for each MSI Or can I set the REINSTALLMODE MSI property to vmous or vamus of A on upgrade? Thanks -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn and chaining multiple MSIs and detecting proper states for each MSI
Possibly. Would need to understand the scenario well to make a recommendation. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: victorwhiskey [mailto:victorhwhis...@yahoo.com] Sent: Sunday, April 12, 2015 9:05 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Burn and chaining multiple MSIs and detecting proper states for each MSI John and Rob, thanks for the reply. All MSIs are using Major Upgrades. The only relationship between B and C is only the shared components in A or A'. And the product code is different between A and A'. Would using a wixlib work or be better than an MSI? Thanks! -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to include an entire folder as payload for my custom bootstrapper application?
List all the files in the folder as Payload elements. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Roni Fuchs [mailto:ro...@microsoft.com] Sent: Sunday, April 12, 2015 6:21 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to include an entire folder as payload for my custom bootstrapper application? Hi everyone, How can I include an entire folder as a payload? License folder instead of a single license, because I have several licenses in several languages ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Fragment PayloadGroup Id=UiPayloadGroup Payload SourceFile=$(var.Common.TargetPath) / Payload SourceFile=$(var.Tri.Common.TargetPath) / Payload SourceFile=$(var.Tri.Deployment.UI.TargetPath) / Payload SourceFile=$(var.Tri.Center.Deployment.UI.TargetDir)\BootstrapperCore.config / Payload SourceFile=$(var.Tri.Center.Deployment.UI.TargetDir)\License / Payload SourceFile=$(var.Tri.Center.Deployment.UI.TargetDir)\Microsoft.Deployment.WindowsInstaller.dll / Payload SourceFile=$(var.Tri.Center.Deployment.UI.TargetPath) / /PayloadGroup /Fragment /Wix Thanks, Roni (Aron) Fuchs -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn and chaining multiple MSIs and detecting proper states for each MSI
I expect A' is a major upgrade of A. There issue is that B knows nothing about A' (and C) and C doesn't have enough information to install A when it uninstalls A'. In this scenario, a repair of B is necessary. Somewhere there was a feature for C to automatically repair B (if there was some bundle relationship between them), that I *think* is in v3.9. However, if you have no relationship between C and B there isn't anything Burn knows to fix it. It's a known gap around a problem that is impossible solve correctly without significant sharing of information between potentially different lineages of WiX code... which we're unprepared to try to solve. Workaround: Repair B. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: Friday, April 10, 2015 2:45 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Burn and chaining multiple MSIs and detecting proper states for each MSI Is A' a major or minor upgrade of A? Is the ProductCode the same or different for A' and A? What is the difference in version numbers? What does the bundle log say when it is selecting A for removal? -- John Merryweather Cooper Senior Software Engineer | Integration Development Group | Continuing Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |jocoo...@jackhenry.com -Original Message- From: victorwhiskey [mailto:victorhwhis...@yahoo.com] Sent: Friday, April 10, 2015 4:08 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Burn and chaining multiple MSIs and detecting proper states for each MSI This is my scenario, I have 2 different bundles, B and C. They each have 2 MSIs chained with a common MSI A or A' (a newer version of A). If I installed bundle B which has A then I install C which has A', I'm expecting B to install B and A, then C to install and upgrade A to A'. I am getting this as the result. However, what I didn't expect was when I removed one product, lets say C, MSI A was removed breaking bundle B. Now with my understanding of component counting if I install Bundle B then Bundle C the component counts to all the components in A will be 2 and A will be upgraded to A'. Now when I uninstall either of the Bundles A got removed which is not what I'm expecting. What's wrong in the this logic? I'm expecting MSI A to still be present with the remaining Bundle that I did not uninstall. What can I do to keep MSI A still installed with this type of deployment strategy? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-and-chaining-multiple-MSIs-and-detecting-proper-states-for-each-MSI-tp7599891p7599903.html Sent from the wix-users mailing list archive at Nabble.com. -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
Re: [WiX-users] ICE Validation in CI systems
We'll need Windows Installer team to change the way they implemented ICEs back in 1998. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Anthony Foglia [mailto:afog...@gmail.com] Sent: Thursday, April 9, 2015 12:42 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] ICE Validation in CI systems WiX team (and users), we're trying to use WiX on our CI system and failing the ICE validation because the service account does not have administrative privileges. I assume it's the same as this bug, http://wixtoolset.org/issues/3968/ . Has any progress been made on this issue? What are the obstacles to getting WiX to do ICE validation without administrative privileges? -- --Anthony -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using burn to download, unzip, install package
I'd consider shipping the setup.exe (and any support files) in the bundle without the archive wrapper. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: maverick02 maverick02 [mailto:maverick0...@yahoo.com] Sent: Thursday, April 2, 2015 9:28 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Using burn to download, unzip, install package Hi Everyone, I am looking for some guidance on doing the following. I want to bundle a prerequisite package that can be downloaded from a url at install time. The problem is that this package comes as a self-extracting Winzip archive and if the installation is to be silent, I need to do it in two stages: 1. Extract the archive silently to a folder. 2. Run the extracted Setup.exe with some command line switches. It's not clear to me how one would do this with Burn without having a .NET dependency. Any ideas? Thanks. Leor Greenberger -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using burn to download, unzip, install package
I would let Burn do all the downloading but if you can't just create process the package, then you'll have to write something that can be create processed then do the multiple steps. For example, how would Burn know what to do here? It's all custom... which basically comes down to Don't do that but you have to convince the 3rd party to improve their installation story. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: maverick02 maverick02 [mailto:maverick0...@yahoo.com] Sent: Thursday, April 2, 2015 10:14 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Using burn to download, unzip, install package Thank you Rob for the quick reply. Just to be clear, this package that I am bundling is not mine, but is provided by a 3rd party. It is also quite large (at about 70 MB) and so it would be nice if it would download only on demand when its not yet already installed. Are my options essentially: 1) Ship with the extracted setup.exe in the bundle. or 2) Write a .NET library to perform the downloading, extraction, and installation? Thanks. - Original Message - From: Rob Mensching r...@firegiant.com To: General discussion about the WiX toolset. wix-users@lists.sourceforge.net Cc: Sent: Thursday, April 2, 2015 12:51 PM Subject: Re: [WiX-users] Using burn to download, unzip, install package I'd consider shipping the setup.exe (and any support files) in the bundle without the archive wrapper. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: maverick02 maverick02 [mailto:maverick0...@yahoo.com] Sent: Thursday, April 2, 2015 9:28 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Using burn to download, unzip, install package Hi Everyone, I am looking for some guidance on doing the following. I want to bundle a prerequisite package that can be downloaded from a url at install time. The problem is that this package comes as a self-extracting Winzip archive and if the installation is to be silent, I need to do it in two stages: 1. Extract the archive silently to a folder. 2. Run the extracted Setup.exe with some command line switches. It's not clear to me how one would do this with Burn without having a .NET dependency. Any ideas? Thanks. Leor Greenberger -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix bootstrapper only works on .net 4.5
NETFX v4.5 is an in place upgrade of v4.0. If you have v4.5 you no longer have v4.0 on your machine. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Lutteke, Robin [mailto:robin.lutt...@ordina.nl] Sent: Monday, March 30, 2015 6:46 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Wix bootstrapper only works on .net 4.5 Just changed my custom bootstrapper to .Net 4.0, but it still is running only under .Net 4.5. My bootstrappercore.config looks like: ?xml version=1.0 encoding=utf-8 ? configuration configSections sectionGroup name=wix.bootstrapper type=Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperSectionGroup, BootstrapperCore section name=host type=Microsoft.Tools.WindowsInstallerXml.Bootstrapper.HostSection, BootstrapperCore / /sectionGroup /configSections startup useLegacyV2RuntimeActivationPolicy=true supportedRuntime version=v4.0 / /startup wix.bootstrapper host assemblyName=PcaBootstrapper.SetupBootstrapper supportedFramework version=v4\Full / supportedFramework version=v4\Client / /host /wix.bootstrapper /configuration When I start the setup I'm getting a dialog with the message that the setup has stopped working. What can I do to force the setup to use .Net 4.0? The log file is showing: [0CA0:0F74][2015-03-30T15:42:51]i001: Burn v3.9.1208.0, Windows v6.1 (Build 7601: Service Pack 1), path: C:\Users\george1\Desktop\Test.exe, cmdline: '' [0CA0:0F74][2015-03-30T15:42:51]i000: Initializing string variable 'SELECTEDFEATURES' to value '' [0CA0:0F74][2015-03-30T15:42:51]i000: Initializing string variable 'InstallDir' to value '[ProgramFiles6432Folder]Test' [0CA0:0F74][2015-03-30T15:42:51]i000: Initializing string variable 'IPADDRESS' to value '' [0CA0:0F74][2015-03-30T15:42:51]i000: Initializing numeric variable 'LANGUAGE_NR' to value '0' [0CA0:0F74][2015-03-30T15:42:51]i000: Setting string variable 'WixBundleLog' to value 'C:\Users\george1\AppData\Local\Temp\Test_20150330154251.log' [0CA0:0F74][2015-03-30T15:42:51]i000: Setting string variable 'WixBundleOriginalSource' to value 'C:\Users\george1\Desktop\Test.exe' [0CA0:0F74][2015-03-30T15:42:51]i000: Setting string variable 'WixBundleOriginalSourceFolder' to value 'C:\Users\george1\Desktop\' [0CA0:0F74][2015-03-30T15:42:51]i000: Setting string variable 'WixBundleName' to value Test' [0CA0:0F74][2015-03-30T15:42:51]i000: Loading managed bootstrapper application. [0CA0:0F74][2015-03-30T15:42:51]i000: Creating BA thread to run asynchronously. [0CA0:0E1C][2015-03-30T15:42:51]i000: Launching Installation Interface Thanks!! Robin Lutteke -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] BAFunctions.dll to set WixBundleName from the language of the user's computer
Often the Programs Features contains the name of the product which is typically a trademark (or treated like a brand in any case) and thus not localized. It's possible to change the name but wixstdba doesn't really expose it easily. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: David Burson [mailto:david_bur...@ntm.org] Sent: Monday, March 30, 2015 9:53 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] BAFunctions.dll to set WixBundleName from the language of the user's computer Thanks Phil, I’m just trying to make sure that when a user tries to uninstall my software, they can find it in Programs Features (or when they are looking through Programs Features, they don’t uninstall it because they don’t know what it is). That means the name that Programs Features displays needs to be what they think of as the name of my program, which is different for each language. I’d obviously rather not write my own BAfunctions.dll if I can avoid it. I’m new to all this so I appreciate your patience as I try to understand my options. I’ve studied the link you provided and the other links in it, but still have not come up with a working solution. Towards the beginning of the discussion you referenced below, you provided a link on how to localize the Product name of an msi, and said (It happens to be in a MSI Product element but also could be implemented in a Bundle element.)” But when I add a string for “WixBundleName” to my wxl’s, it seems to be ignored. Herehttp://stackoverflow.com/questions/29266905/wix-toolset-how-to-create-a-single-exe-with-product-name-localized-for-multiple/29270124?noredirect=1#comment46810219_29270124 is my SO question, which led me to think I need to create a BAfunctions.dll. I thought it might be more appropriate to move my ongoing questions to this email list, rather than continue in SO - please correct me if I’m wrong! Anyway, thanks to a number of posts by you and others (and the wix toolset site), my installer works great. All strings (including the name of my program) are presented in the user’s language. The one issue left is the name that is displayed in Programs Features. In my SO question above the original answer mentioned a cool feature not yet being worked on that, if I understand correctly, will localize the name in Programs Features even if the user changes languages after installing the program. While that may be ideal, it’s more than I need. Really, all I need is for Programs Features to display the same name I show to the users at install time. Currently that is a variable I define for each language I support, since I’ve not been able to figure out how to change [WixBundleName]. Some of my constraints: - I cannot go the route of including different msi’s in my bundle (one per language), since each msi is about 250 MB. - I cannot simply have my users download the appropriate msi for their language. Typical distribution (which I can’t control) is an English speaker installs the software for themselves, and gives their installer to nationals who don’t speak English. So the single installer needs to “just work” for the languages I support. - Additionally, many of my users have no reliable internet connection. My program does not use .NET. I’m not currently using Visual Studio, though if necessary in order to solve this issue I have VS 2010 and of course the free VS 2013 available. I just can’t add .NET or other large dependencies. Another path I’ve gone down is to not give my bundle a name at all, and set Visible=“yes” in my msipackage, and try to figure out what Tobias S meant by the “normal” way in this conversationhttp://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Deploying-multiple-cultures-using-Burn-MSI-s-Wix-3-9-issue-td7596896.html. That works fine, even though uninstalling from Programs Features doesn’t use my bundle UI (I can live with that), but the deal-killer is that after uninstalling via Programs Features, when I try to re-install by running my installer, it thinks it’s still installed. Which makes sense - the bundle is distinct from the program I’m installing - but the user doesn’t see it that way. I’m still trying to understand: am I really the only person that needs a single installer without duplicating an msi for each language, and needing to localize the program name in Programs Features? How do people normally do this? Surely it’s not normal to rely on users knowing enough English to understand the English name of every program they install, and be able to figure out from the English name what program it is? Thanks very much for any guidance anyone can give me! David -- Dive into the World of Parallel Programming The Go Parallel
Re: [WiX-users] Wix bootstrapper only works on .net 4.5
I did not say that at all. If you want code to run against v4.0 you need to target v4.0. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Lutteke, Robin [mailto:robin.lutt...@ordina.nl] Sent: Monday, March 30, 2015 10:55 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Wix bootstrapper only works on .net 4.5 So, because I've got .Net 4.5 installed on my system I cannot create a custom bootstrapper setup for .Net 4.0? Met vriendelijke groet, Robin Lutteke Software Engineer Ringwade 1 3439 LM Nieuwegein T +31(0)30 663 8000 (optie 1) F +31 (0)30 663 8010 www.ordina.nl -Original Message- From: Rob Mensching [mailto:r...@firegiant.com] Sent: maandag 30 maart 2015 18:17 To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Wix bootstrapper only works on .net 4.5 NETFX v4.5 is an in place upgrade of v4.0. If you have v4.5 you no longer have v4.0 on your machine. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How does heat maintain consistent GUIDs?
so I don't make mistakes based on an incomplete comprehension - very wise. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Pat Blair [mailto:p...@daburu.net] Sent: Sunday, March 29, 2015 7:12 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How does heat maintain consistent GUIDs? I am curious to know how WiX keeps track of GUIDSs automatically generated for files when we use HeatDirectory. For example, I have a project with the following in my .wixproj file... Target Name=BeforeBuild PropertyGroup WixToolPathC:\SourceControl\WiX39\/WixToolPath /PropertyGroup HeatDirectory ToolPath=$(WixToolPath) Directory=C:\users\me\Desktop\SourceFiles ComponentGroupName=MyComponentGroup DirectoryRefId=INSTALLFOLDER AutogenerateGuids=true GenerateGuidsNow=false SuppressFragments=true SuppressRootDirectory=true PreprocessorVariable=var.SourceFilesDir OutputFile=Components.wxs / /Target If I set AutogenerateGuids=true, my output file contains components like this: Component Id=cmpA609F30B9E3AECCDEE4D779C8B7308ED Guid=* File Id=fil314398091041DF4762128892E7C98AA7 KeyPath=yes Source=$(var.SourceFilesDir)\Sample1.txt / /Component I note that Component/@Guid=*. After generating the .MSI, I open it with Orca and see that the ComponentId for each Component (for each file) is the same. If I change my HeatDirectory element so that AutogenerateGuids=false and GenerateGuidsNow=true, the ComponentIds seem to change. If I understand correctly, this is how it should work and by using AutogenerateGuids, my installers can track a given file from install to install. I also think I understand that the GUIDs will remain the same so long as the file names and paths to which they are installed doesn't change, so this approach will let me do minor upgrades because the installers can tell that two versions of a file from two different installers are the same component because the ComponentIDs match. But what I'm wondering is: How are these consistent GUIDs that I get when I use AutogenerateGuids=true remembered from build to build? Are they generated by some algorithm that will always produce the same GUID for a file with a given name installed to a given directory, or are they stored somewhere. And if they are stored somewhere, where are they stored? I'm hoping this isn't a dumb question, but I feel like I need to understand this before using the feature so I don't make mistakes based on an incomplete comprehension of what's happening behind-the-scenes. Many thanks. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Keep Desktop Shortcuts and Pinned Task Bar Icons with Upgrades
Schedule your upgrade late and carefully adhere to the Component Rules. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Tobias Markmann [mailto:tmarkm...@googlemail.com] Sent: Wednesday, March 25, 2015 4:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Keep Desktop Shortcuts and Pinned Task Bar Icons with Upgrades Hi, I'm currently trying to fix remaining issues in our WiX-based installer. The current issue I'm trying to fix is WiX/MSI behavior when upgrading an installation. Upgrading mostly does an uninstallation of the previous version and installs the new version. This automatically means that shortcuts of the old version are deleted and new shortcuts installed. This process has two issues: 1. If the user has pinned an application to the task bar, the deinstallation will result in a broken shortcut in the task bar. 2. The position of desktop shortcuts is lost because the desktop shortcut is deleted and a new one is installed. (I don't use desktop shortcuts yet.) I've tried some hacks/workarounds found on the internet. None of them worked for me. Last change I tried is using MajorUpgrade RemoveFeatures=Core ... /, with 'Core' describing all features except the shortcuts. This basically worked, pinned shortcuts still worked. However, there is the ugly side effect that the old version is still registered under Programs Features, probably because I told to keep the shortcuts. How do you handle this issue? Is there a way to migrate the old version Shortcuts to the newer version Shortcuts? Is there some diff method, so MSI detects that the upgrade will basically setup the same shortcuts so that it won't remove them in the first place. Thanks for any pointers and cheers, Tobias -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Prevent run of Custom action if product is installed.
RemoveFoldersEx? _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Sarvagya Pant [mailto:sarvagya.p...@gmail.com] Sent: Monday, March 23, 2015 9:05 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Prevent run of Custom action if product is installed. I need to Remove Folders as well. RemoveFile only works to delete the File, I think so. The executable could create Folder within folder and files too. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
