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
UNOFFICIAL
I am using Wix version 3.9
Regards
Scott Brown
-Original Message-
From: wix-users-requ...@lists.sourceforge.net
[mailto:wix-users-requ...@lists.sourceforge.net]
Sent: Wednesday, May 20, 2015 3:15 AM
To: wix-users@lists.sourceforge.net
Subject: WiX-users Digest, Vol 108,
When a .NET package is successfully installed as a prerequisite for our Burn
bootstrapper application, and the user cancels the install, the bootstrapper
package is still listed in the Add/Remove programs. I understand that the .NET
package is part of the bundle but from a user's perspective
Ok Let me try this time to state the problem:)
We have a legacy setup installer(based on wix 3.0) that installs the core
engine features. We are developing a new setup installer(based on wix 3.8)
that installs tools features. Based on the current code they both share a
common msi(which is
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
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
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
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.
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/
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
To me at least that's not the problem you're describing - that's a
restatement of your solution, the implementation of which is to block
an MSI install if another product is already installed. Anyway, it
looks like you'll need to write code to do this as outlined earlier
based on detection of an
I use a bundle to drive my msi packages. Generally I use
util:RestartResource but some time ago I used util:CloseApplication. I do
not recall observing the scenario that you described, however I do know that
the underlying API used in either case, util:RestartResource or
util:CloseApplication,
In each msi use the MajorUpgrade element and increment the first three
sections of the MSI version (i.e 1.0.0.0 to 1.0.1.0, and not 1.0.0.1)
When building the second release of the bootstrapper, leave all of the MSIs
in the first release in the chain and only change the MSI B if that is what
is
So how can I detect if a Burn Bundle Exe package is installed, from another
bundle setup package?Can you provide some kind of example?I have seen the
RelatedBundle, but how can I use it to set the Detect condition of an exe
package?Thanks
From: jacob.hoo...@greenheck.com
To:
I have done some experiments with 'bob' (bundle of bundles). I may not have
it all figured out yet, but what I have done is this:
1) Add this to the parent bundle (I do this for every bundle, even when not
planning to do 'bob', so that in the future I can decide to create a related
Addon or
The fact that it works when used from the MSI instead of the bootstrapper
means that application contexts are not the problem. In the meantime I
found a conversation on wix-devs which implies that this won't be
implemented any time soon. Fine.
What I ended up doing for now is writing a
Set the Name attribute to the name you want.
--
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:
Is there any easy way to deliver a file with a different name?
I have:
Component Id=readme.txt Guid=*
File Id=readme.txt KeyPath=yes
Source=$(var.PATH_TO_PROJ)viewer.readme.txt /
/Component
And I need to deliver the viewer.readme.txt file as readme.txt.
Is there an easy way to do this
18 matches
Mail list logo
