My 2 cents, a vbscript's function :
' Prerequisites
' Proprierty FILE : File Path + Its name
' Propriété LINE : what you want to replace
' Propriété REG_EXP : Reg exp to identify what you want to be replaced
' Theses 3 properties are passed throught CustomActionData's property.
'
Sub
You mean Minor upgrade to replace the msi cache file?
I want to change(arguments passed to custom actions), remove custom actions
which are supposed to execute on RemoveExistingProducts. Is it possible via
Minor upgrade? or please suggest me some other easier method if any than
supplying an
Hello,
in my msi package i want to download a file from the internet. I read that msi
has no posibility to download files so I created a custom action which handles
the download for me. But now I got stuck. I don't know how to get the
connection between my component and the custom action. A
Simply, you need to force a recache/reinstall (msiexec /fv) with a new MSI
(that is fixed) that has the same ProductCode. This looks basically the
same as a minor upgrade.
On Thu, Apr 4, 2013 at 3:37 AM, Subbiah Ganesan subbiahtv...@gmail.comwrote:
You mean Minor upgrade to replace the msi
That will be very challenging. You don't want to lie to the MSI about what
file is on disk. IOW, the MSI should know what file is being installed,
changing it on the fly would require changing the MSI and that'll also be
challenging (and I believe impossible) while the MSI is running.
On Thu,
This sounds like a configuration task that is best handled outside
installation. Install your file to a neutral safe area in your installation -
somewhere it can be safely repaired without breaking anything. Attempt your
download, then copy either your safe file or the downloaded one into the
Well, played, David.
On Thu, Apr 4, 2013 at 7:05 AM, David Watson dwat...@sdl.com wrote:
This sounds like a configuration task that is best handled outside
installation. Install your file to a neutral safe area in your
installation -
somewhere it can be safely repaired without breaking
Hello Dave,
and can this installation task started from my msi package after installation
is done?
Thanks,
Georg
-Ursprüngliche Nachricht-
Von: David Watson [mailto:dwat...@sdl.com]
Gesendet: Donnerstag, 4. April 2013 16:06
An: General discussion for Windows Installer XML toolset.
If you have no facility for first run (or per user) configuration in your
application then this is indeed usually done at the end of the installation
process.
If conditioned correctly your installer will also re-download and re-apply
the file in a repair.
-Original Message-
From:
We ended up using a PostBuild event to call a bat file that renames the msi
to include the configuration.
1. In the Wix project, we added a BatFiles folder containing RenameMSI.bat
2. In the Wix project properties, we added this to the Build Events,
Post-build Event Command Line
call
Hello all,
We had a requirement to show the configuration in the msi name because we
have several validation steps along the way. For the benefit of others, here
is how to do it using PostBuild events to call a bat file which renames the
file. The system supplied parms pertaining to path all
Why not just change the TargetName property in MSBuild?
On Thu, Apr 4, 2013 at 9:15 AM, j2associates j2associa...@yahoo.com wrote:
Hello all,
We had a requirement to show the configuration in the msi name because we
have several validation steps along the way. For the benefit of others,
I had to do something similar in our build because the MSI names needed the
version number. The way I accomplished this is
In the wixproj I changed the OutputName to
OutputNameMyMsi$(OutputSuffix)/OutputName
And when I build the msi using msbuild I just pass and OutputSuffix like so
Hi,
If I have two bundles B1 and B2.
B1 installs MSI A v1.0 and MSI B v1.0.
B2 installs MSI A v2.0 and MSI C v1.0.
Currently if I install B1 after B2, B1 will downgrade MSI A to version 1.0.
How can I prevent this? It seems like the MSI itself cannot control this (I
have major upgrade
You're sure setting the DowngradeErrorMessage attribute of the MSI A's
MajorUpgrade element doesn't do the trick? It seems to work
for me.
Alain
-Original Message-
From: Wesley Manning [mailto:wmann...@dynagen.ca]
Sent: April 4, 2013 14:13
To: General discussion for Windows Installer
In the MajorUpgrade use the downgrade element:
MajorUpgrade DowngradeErrorMessage=A newer version of
$(var.PlatformProductName) is already installed. Setup will now exit.
Schedule=afterInstallValidate AllowDowngrades=no/
-Original Message-
From: Wesley Manning
Hmm really? Maybe I did something wrong. I tried this a few months ago and
am coming back to it. I'll try it again.
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: April-04-13 3:17 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re:
My bet is that something is awry in the upgrade logic on the MSIs. If you
look at the Burn log, the plan should show you what it is doing for each
MSI. That plus the Upgrade (or MajorUpgrade) elements can explain a lot
about what is going sideways.
On Thu, Apr 4, 2013 at 11:16 AM, Alain Forget
Thanks. I think I did that except for AllowDowngrades=no which is the
default action I believe.
Wes
-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: April-04-13 3:22 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users]
Yes, that would be cool. Please open/create a feature request on the system
used to track these things, so it's not forgotten. Hopefully someone with
knowledge of WiX internals will be able to provide the functionality.
-Original Message-
From: Rob Mensching
You only need to want to learn. Waiting for someone else to get to it...
well, you might be waiting a while.
On Thu, Apr 4, 2013 at 3:43 PM, Alain Forget afor...@cmu.edu wrote:
Yes, that would be cool. Please open/create a feature request on the
system used to track these things, so it's not
21 matches
Mail list logo
