Hi,
I am creating a patch for my installer. I have my base version installer
and new installer. when I try to create patch, It fails(logs attached).
my base installer and new installer having different product(@Id) and
package(@Id). Please suggest if anybody have a workaround for this.
Hi
Thanks for your answer. From how i interpret the log file the action returns
success (even if there is an exception), which is no surprise as I return this
result via C#. Here are the relevant parts from the log:
TestCA.SetProperty 3
MSI (s) (54:54)
Hi
Thanks for your answer. Having a launcher exe seems to be the save way to go.
In the meantime, i noticed that on some machine it works as supposed, using the
following custom action definiton:
CustomAction Id=LaunchPrintProcessAction Directory=PrintProcessDir
Return=asyncNoWait
WOW!
GenericRead + Traverse really works for Read!
Why it has such an interesting behavior? Is it a bug or by design?
The GenericRead='yes' Traverse='yes' seems to give Read.
--
View this message in context:
Ok, I opened bug 3029343 for the issue.
Andreas Hirth
-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com]
Sent: Saturday, July 10, 2010 5:01 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Registry permission for key and subkeys
On 7/9/2010 12:23 PM,
Hi
Since I haven't managed to assign the [SourceDir] value to a customAction Data
Property, i tried to assign the data assign the value to a property and then
assign that property to the a customAction. However, no success, the assigned
property is empty. I am sure it is a simple syntax thing
Hi
I still havent figured out how to solve my issue, but i have found a couple of
other aspects. As it seems, the built in property: [SourceDir] is, depending at
the time of exeuction, sometimes empty. In the execute sequence, if i use a
immediate custom action, scheduled after
The SourceDir is set by ResolveSource. The actions using this property
should be scheduled after this action (see
http://msdn.microsoft.com/en-us/library/aa371857(VS.85).aspx).
-Original Message-
From: daniel.knoep...@noser.com [mailto:daniel.knoep...@noser.com]
Sent: Wednesday, July
Hi and halleluja
I finally managed to access the SourceDir Property in the CustomAction data.
The reason i could not access the SourceDir property earlier was simply that I
scheduled the customAction to assign the properties to the CustomActiondata to
early (It seems UI-sequence and execute
http://msdn.microsoft.com/en-us/library/aa370579.aspx
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited.
Nothing like pressure, but my first Wix Install is being released to clients
on friday and I am struggling to prevent a downgrade. The product id is set
to a guid and the package id to *, the upgrade code it set to the parameter
in the prodcut.
The relevant code is below, I was expecting an
I use
Upgrade Id=$(var.UpgradeCode)
UpgradeVersion Minimum=$(var.Version) IncludeMinimum=yes
OnlyDetect=yes Property=NEWERVERSIONINSTALLED /
/Upgrade
Condition Message=A newer version of this product has been
detected on your system. Setup cannot continue and will now
Hello everyone,
I was wondering, when i have a global property which gets it's value
only from let's say an Edit Field in a dialog,
should i define it in my main wxs file as well?
i.e
Property Id =CONNECTIONSTRING Value=0/
or not?
The reason i ask is because even if i don't add the above line,
You don't have to. And the condition equal to the name of the property
will check if it was defined, that is, if the user entered anything to
your edit box.
-- Yan
-Original Message-
From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net]
Sent: Wednesday, July 14, 2010 17:04
To:
OK I'm even more confused, how does that prevent a downgrade?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Preventing-downgrade-of-version-tp5292363p5292763.html
Sent from the wix-users mailing list archive at Nabble.com.
Blair, as always, thanks for your replies! Unfortunately, this time I came
up empty :(.
I did the following but still ended up with a duplicate of my applications
installed in Add/Remove Programs after the Installer finished:
- I modified my upgrade element as follows:
Hahaha nevermind... I see that I totally got it backwards... I reversed my
OnlyDetects below and it works great... You rock... Sorry!
-Jeremy
On Wed, Jul 14, 2010 at 9:20 AM, Jeremy Rimer jeremyri...@gmail.com wrote:
Blair, as always, thanks for your replies! Unfortunately, this time I came
Hello,
I am working on creating a wix installer to upgrade an existing application.
If I try to install an older version of the application, the installer
indicates that a newer version is installed and exits the setup as expected.
The issue I am having occurs when a newer version is
I have one last problem before my installer is completely working:
I have a custom EXIT dialog that I created called MyExitDialog that contains
an extra button that spawns a custom dialog to gather application settings
from the user to write into the App.Config file that was deployed and/or
I must also add that under my custom exit dialog, I have this:
==
InstallUISequence
Show Dialog=MyExitDialog
OnExit=success![CDATA[INSTALLED]]/Show
/InstallUISequence
AdminUISequence
Show Dialog=MyExitDialog OnExit=success
If you simply remove the older version (without installing the newer
version), do the shortcuts remain?
What is your associated code for the shortcuts in both old and new versions?
-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com]
Sent: Wednesday, July
If you have code that causes the application(s) detected to shutdown
(including using the built-in actions to stop services you install) the
restart manager-related detection code doesn't always acknowledge that. As a
result the user is often told of a need for reboots that ultimately are
never
INSTALLED is still undefined at the end of the initial install.
So you would want the condition below to be NOT INSTALLED to be true for the
initial install.
-Original Message-
From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
Sent: Wednesday, July 14, 2010 10:25 AM
To: General
But I don't want to restart unconditionally. Only when the user chooses
to stop the Restart Manager from closing the offending applications. Is
there a way to detect that?
I'm reading the documentation for the REBOOT property here:
http://msdn.microsoft.com/en-us/library/aa371101(VS.85).aspx
Could your custom action be written such that it simply exits early with a
success code if it doesn't find the App.Config file?
-Original Message-
From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
Sent: Wednesday, July 14, 2010 8:25 AM
To: General discussion for Windows Installer XML
I put ![CDATA[NOT INSTALLED=1]] in those Show elements, but it still
showed the MyExitDialog in both the Remove and Install paths... ?
On Wed, Jul 14, 2010 at 10:55 AM, Dan Hoeger dan.hoe...@microsoft.comwrote:
INSTALLED is still undefined at the end of the initial install.
So you would want
Yes, the shortcuts do remain if I remove the older version without installing
the newer version.
Code for shortcuts in new version:
!-- Declare Start Menu Shortcuts --
DirectoryRef Id=ProgramMenuFolder
Directory Id=TFirmwareUtilFolder Name=$(var.ProductName)
Component
The product id is set to a guid. I suppose based on that text that the
ProductCode GUID doesn't change between the versions?
FindRelatedProducts and RemoveExistingProducts do not run during maintenance
transactions. A maintenance transaction always runs when the ProductCode of
the current package
If you didn't replace one of the files that were discovered to be in use,
then no, you won't get an automatic reboot prompt. Which file did you
replace when you uninstalled your application?
-Original Message-
From: Ivo Beltchev [mailto:i...@roadrunner.com]
Sent: Wednesday, July 14, 2010
This is a shell extension and the DLL is used by the Explorer process.
There are two scenarios:
1) Uninstall - no file is actually replaced, simply deleted.
2) Upgrade - the DLL is replaced by a new version.
The Restart Manager correctly identifies that the DLL is in use by
Explorer and offers
Unfortunately not with the way it is currently written...
This custom MyExitDialog occurs at the right time during every run of the
installer, in lieu of the WIX standard ExitDialog. I have a button on it
that spawns an extra dialog (if you don't press finish instead, which quits
the installer),
Wouldn't it be better to ask the user the configuration questions during
the UI Sequence make the modifications to the app.config using
XMLConfig as part of the install process? That way you could condition
when your dialog is shown more appropriately instead of needing multiple
ExitDialogs and
funny you mention that... The original requirements of this installer were
to prompt the user the defaults provided in the App.Config file of the
deployed program, which meant that we COULDNT prompt the user for settings
before the files were copied. It turned out that particular action was
Condition the button to be hidden if REMOVE=ALL ?
-Original Message-
From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
Sent: Wednesday, July 14, 2010 9:25 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Conditionally Show Dialog Button based on
Hmmm...
I did this:
===
InstallUISequence
Show Dialog=MyExitDialog
OnExit=success![CDATA[REMOVE=ALL]]/Show
/InstallUISequence
AdminUISequence
Show Dialog=MyExitDialog OnExit=success
![CDATA[REMOVE=ALL]]/Show
/AdminUISequence
===
and it still shows it on
To be more specific...
It seems that with ![CDATA[REMOVEALL]] in there, It shows the
MyExitDialog in BOTH scenarios...
I even tried putting something like this in:
==
InstallUISequence
Show Dialog=MyExitDialog
OnExit=success![CDATA[REMOVEALL]]/Show
Show Dialog=ExitDialog
Use MyExitDialog always, and hide the button in that dialog that runs your
CA.
-Original Message-
From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
Sent: Wednesday, July 14, 2010 11:04 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Conditionally
Here's MyExitDialog:
Dialog Id=MyExitDialog Width=370 Height=270
Title=!(loc.ExitDialog_Title)
Control Id=Finish Type=PushButton X=224 Y=243 Width=56
Height=17 Default=yes Cancel=yes Text=!(loc.WixUIFinish) /
!-- The following Control allows us to go beyond finish
You have to specify what action the condition will invoke. In this case, I
would assume you would use Action=hide in your Condition element under
your control.
Control Id=ApplicationSettings Type=PushButton X=94 Y=243
Width=130 Height=17 Default=no Cancel=no Text=Modify Application
Upon further review...
The requirement is to support multiple instances of my product on the
same machine. There is a related product that uses InstallShield for
their packaging. I need to allow the person installing the product to
pick one of those instances. I just need to read the registry,
In scenario #1, Windows Installer will not by default [prompt for] reboot.
In scenario #2, there are two possibilities:
2.1 - RemoveExistingProducts is scheduled early and this is a major upgrade:
Removal of the old file occurs before writing of the new file: no [prompt
for] reboot (same as
Then you have done nothing wrong in your new version (assuming it does
remove its shortcuts). You could use the RemoveFile element in WiX to remove
the previous shortcuts on installation.
-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com]
Sent: Wednesday,
Thank you!
The new version does remove its shortcuts.
If I use the RemoveFile element on an update, if the file doesn't exist when it
tries to remove it, will an error occur?
If so, how do I check to verify that the files do exist?
Thanks,
Katelyn
-Original Message-
From: Blair
M I think we're on the right track, but using what you have below NEVER
shows the button, regardless of REMOVE path or INSTALL path... are there any
other conditionals that would match those states at the time this dialog is
shown? (which is AFTER install)?
On Wed, Jul 14, 2010 at 1:33 PM,
OK, so basically you are saying that the restart prompt is only supposed to
appear during an upgrade when a file is being replaced.
In my case I'm always using a major upgrade, so the old version is uninstalled
first, then the new one is installed. No file is directly overwritten.
It is a bit
Hello all!
Let's say that i am using a C# custom action, to validate the database
connectionstring that a user has entered in a dialog.
If the user has selected to use Integrated Security, and the account of
the Windows Service that will be running the application is Local
System,
that would mean
I have used the XMLConfig and XMLFile in Wix 2.0 and they work fine for adding
new items. However, I am unable to use these to append to existing values. Is
there a way to append an XML file using Wix 2.0?
I am attempting to take the following XML:
?xml version=1.0 encoding=utf-8?
XmlFile
Believe it or not, there is a saying oft repeated in the hallways at Microsoft:
Reboots are evil. The current design in Windows Installer is to request a
reboot only when under no reasonable scenario can the reboot be avoided (such
as an upgrade of a running program when the program won't die
Non-matches are ignored, so no error will occur.
-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com]
Sent: Wednesday, July 14, 2010 12:04 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade Help
Thank you!
The
If your setup stub file is similar to setup.exe, you can use setupbld.exe to
configure your setup file you use to replace the wix-supplied setup.exe stub
file.
-Original Message-
From: Durwin Wright [mailto:durwin.wri...@ingres.com]
Sent: Wednesday, July 14, 2010 11:48 AM
To: General
Right. So basically the Windows Installer/Restart Manager combo don't work very
well for shell extensions that can be loaded in various processes.
Probably the best thing I can do is try to detect the user's response to the
Restart Manager prompt run a ScheduleReboot action if the user has
The custom actions used in the WixSQLExtension do not have the
no-impersonate bit set, so they never run as LocalSystem (except in the
rare instance that the installation were being performed by a service
running as LocalSystem). Thus, if you are using the WiX-supplied SQL support
you must launch
You need to be careful here because it may not always work. You have
impersonate=no in your custom action so you're running with the local system
account. If you get to a situation where somebody is installing your setup from
a network share it's unlikely to work because the system account
That would not help in my case though, since i am aiming to validate any
user defined values entered in the UI sequence.
So in the case where the user chooses to run the service to be
installed as LocalSystem, and the connectionstring uses integrated
security, i want to make sure that the
There's the rub, I do need to do patch upgrades, so I assume on that basis I
am correct.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Preventing-downgrade-of-version-tp5292363p5294924.html
Sent from the wix-users mailing list archive at
Since you are allowing patch upgrades, it is the responsibility of your
bootstrapper to validate that no downgrade is occurring when applying a new
package with the same ProductCode as an already installed package. You must
make sure that your bootstrapper is up to the task.
-Original
56 matches
Mail list logo
