According to the patching whitepaper, it's impossible for both patches to
supersede each other - one has to be a later in the sequence than the other,
so in the usual one family scenario it isn't going to work.
The default validation flags are to match all 3 fields of the targets product
Hello,
I have placed 2 radiobuttongroup controls in the same dialog but the radio
buttons in the second group appear to be disabled and so the selection can't
be changed.
The radio buttons in the first group work fine.
Can anyone please explain what I am doing wrong?
Thank you,
Anil.
In our development environment, we are installing to an existing website
hosted in IIS 7 (Server 2008). However, in our QA environment, we are
installing to an existing site hosted in IIS 6 (Server 2003). I've found
that in IIS 6, the existing website can't be found unless we add the
SiteId=*
We've had quite a bit of hands on experience with this sort of thing lately.
In one project, we bound a certificate to a port during the install so that
we could use SSL (the same as if you were to go into IIS and set the binding
and choose a certificate). In another case, we used ws-security in
Based on the example in the book WiX: A Developer's Guide To Windows Installer
XML, I added an Upgrade element along with a launch Condition inside my
Product element to detect older versions and remove them during installation.
That part works wonderfully. However, when I run the
You'll need to generate a verbose log file.
Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail
-Original Message-
From: Joe Tilley
I am using a managed bootstrapper application and I am trying to figure out
how to detect if the bundle is already installed.
I am able to detect the packages by handling the *DetectPackageComplete*
event but I can't just assume that the bundle is installed by detecting one
of the packages in it
I am trying to create a file share using Wix. Here is the fileshare fragment
I'm using:
!-- Begin file shares --
DirectoryRef Id=SharedMQStorage
Component Id=FileShareComponent
Guid=A89F990A-051B-494D-A958-D71A14724E10
CreateFolder /
util:FileShare
I'm not sure if you ever got this figured out. If not, can you show us the
markup for the custom action?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Executing-a-Batch-File-during-Install-tp6579146p6646053.html
Sent from the wix-users mailing
Could you show the markup you're using for the controls?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Multiple-RadioButtonGroup-controls-in-the-same-dialog-tp6644681p6646096.html
Sent from the wix-users mailing list archive at Nabble.com.
Hi,
I am getting two errors when my installer does a rollback. An 1101 error (A
file stream could not be opened) then a 1712 error (A file needed for system
restore is missing). The rollback appears to have all worked correctly, so
this isn't a huge issue. It is just an annoyance since each one
It should also be noted that if I run an Administrative console and uninstall
the msi from there, the feature gets correctly removed. Even though this msi is
installed not as an administrator, though I am logged in as an administrative
user.
- Original Message -
From: The Eligible
Hi
trying to run exe files with the WiX custom actions and it looks like setup
does not wait for the exe to complete. It's configured as deferred action
with return=check and impersonate=no.
I've see the setup is now installing files before the custom action has been
finished it's execution.
I'm interested in Burn so I've uninstalled Wix35 and am now trying to
load Wix36. The installer appears to hang and just shows Installing in
the upper left and Up to date in the middle left. What's the deal?
--
That won't be an issue if the dialog is only scheduled in the
InstallUISequence as that is skipped on an unattended install.
Neil
-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: 01 August 2011 18:05
To: General discussion for Windows Installer XML toolset.
Hi Everyone,
I am trying to build a very simple ManagedBootstrapperApplication and for
some reason I am getting the following error every time I run my executable.
[0558:0EAC][2011-08-02T15:34:29]: Burn v3.6.1929.0, path:
C:\Users\ppodlevsky\Desktop\Bootstrapper1\bin\Debug\Bootstrapper1.exe,
Possibly configuring Visual Studio?
Can you go in %TEMP% and look at the WiX log files there... that will help
us diagnose futher.
On Tue, Aug 2, 2011 at 1:48 PM, wix-user wix-u...@cornerbowl.com wrote:
I'm interested in Burn so I've uninstalled Wix35 and am now trying to
load Wix36. The
IIRC, test.config must be called BootrapperCore.config. It's the config
for the BootstrapperCore.dll not for your .dll smile/
On Tue, Aug 2, 2011 at 4:17 PM, Phil Podlevsky philpodlev...@gmail.comwrote:
Hi Everyone,
I am trying to build a very simple ManagedBootstrapperApplication and for
Can you share the exact code causing the problem? I agree that it should
work.
On Tue, Aug 2, 2011 at 1:14 PM, Marc Bauer marc@gmx.net wrote:
Hi
trying to run exe files with the WiX custom actions and it looks like setup
does not wait for the exe to complete. It's configured as deferred
Hi Rob,
Thank you so much for your very prompt reply! I knew it had to be something
trivial.
Renaming test.config to Test.BootstrapperCore.config and changing the line:
Payload SourceFile='Test.config' /
to
Payload Name='BootstrapperCore.config'
SourceFile='Test.BootstrapperCore.config' /
You know if you were installed *much* earlier than detection. smile/ The
Application.Command struct has a ResumeType in it that tells you whether
your bundle is registered or not. The ResumeType.Arp is a little misleading
and could probably better be named Registered.
On Tue, Aug 2, 2011 at
If you schedule the MSI for removal (aka: plan = absent) then your request
states for Features will be trumped by the MSI removal. To remove features,
you need to ensure the MSI is at least present, then modify the Feature
states to remove them.
On Tue, Aug 2, 2011 at 1:02 PM, Shruthi Achutha
Ug, batch files? It doesn't look like this supports repair and thus won't
work for patching or minor upgrades (probably all scenarios you cut). Of
course, no error reporting either.
A better way is to build a declarative custom action that is reusable. There
is already one in WiX-contrib
Looking forward to getting feedback about what doesn't work in Burn, yet.
smile/
On Tue, Aug 2, 2011 at 5:33 PM, philpodlev...@gmail.com wrote:
Hi Rob,
Thank you so much for your very prompt reply! I knew it had to be something
trivial.
Renaming test.config to Test.BootstrapperCore.config
I have a setup that installs as v1.0.0. Then I have a created a patch that
updates to v1.0.1 and second patch that will update either a v1.0.0 or v1.0.1
to v1.0.2. This works as expected. These are all minor upgrades (Product and
Upgrade Code stay the same with only changes to the product
Hey.
I have a question regarding the XmlFile element. In my installer, I'm using it
to modify a Unity configuration in an existing installation of another program
(I'm replacing one plug-in with another). The way I'm doing it looks like so:
util:XmlFile Permanent=no Id=SetPlugin
26 matches
Mail list logo
