Those properties in the upgrade table are created when FindRelatedProducts
runs. They should be self-explanatory, but it looks like you need to use
(at a minimum) WIX_UPGRADE_DETECTED instead of OLDERVERSION_BEINGUPGRADED in
those conditions.
Phil
-Original Message-
From: Alain Forget
Looks like you are using the WiX MajorUpgrade element, I think this fragment
should so the same thing as yours:
NOT Installed AND NOT WIX_UPGRADE_DETECTED AND NOT WIX_DOWNGRADE_DETECTED
WIX_UPGRADE_DETECTED AND NOT (REMOVE="ALL")
Installed AND (REMOVE="ALL") AND NOT
> Use orca and have a look at your Upgrade table.
Looks fine to me. Here's the one for version 1.0.2, but the other versions
MSI's look the same (with the appriopriate version 1.0.x):
UpgradeCode VersionMin VersionMax Attributes
ActionProperty
{UPGRADE-GUID}
Use orca and have a look at your Upgrade table.
Do you have OLDERVERSION_BEINGUPGRADED / NEWERVERSION_INSTALLED defined there?
Are the other field values right? (Version Min/Max, Upgrade Code, Attributes)
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Tuesday, Jun
>> But (apparently) just running the installer still works the same, whether
>> it's an MSI or EXE.
> Not sure what you mean by this?
So it's possible for me to install my software using just the unbundled MSI, as
well as part of a bundle (EXE), which is just the same MSI, and a packaged Java
R
Use orca and have a look at your Upgrade table.
-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Tuesday, June 04, 2013 4:19 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Upgrade uninstall restart issue
ARPSYSTEMCOMPON
ARPSYSTEMCOMPONENT just makes the install not appear in ARP so shouldn't make
any difference.
>> But (apparently) just running the installer still works the same, whether
>> it's an MSI or EXE.
Not sure what you mean by this?
I would suggest running the msiexec command from a batch file with th
Yes, I was using msiexec /I originally, before I moved from MSIs to the bundled
EXE. But (apparently) just running the installer still works the same, whether
it's an MSI or EXE.
I found the entry you're referencing:
[15CC:0FF8][2013-06-04T14:35:19]i301: Applying execute package: pkgMyProduct,
I think it is verbose, but I'm not sure. However, your example showed me what
to look for, and I think you're quite right; somehow, when bundled, the 1.0.1
and 1.0.2 MSIs don't seem to be detecting the old version:
MSI (s) (70:30) [14:35:19:652]: Doing action: FindRelatedProducts
Action start 14
If you're restructuring the components and guids then you must run your REP
early to uninstall the old product before installing the new one, such as
after InstallValidate.
Your issue may be that your custom action is immediate because that means
"before any files have been installed. I suspect y
Your log may not be verbose. What you're looking for is something like this
for a proper upgrade detection:
Action start 8:15:57: FindRelatedProducts.
Action 8:15:57: FindRelatedProducts. Searching for related applications
FindRelatedProducts: Found application:
{3B9EA0E2-E0D3-4BA0-A373-7181CFFEF8
Hello,
Sorry I didn't explain that better. Basically in one of our other
installers for a different product I do have the RemoveExistingProducts
scheduled early however if I schedule it that early in this installer then the
whole install fails because of the custom actions I posted
I must not be understanding what you mean. As I mentioned in the previous
e-mail, the log indicated that FindRelatedProducts was set to 1, meaning that
it did find the related product, no?
Furthermore, the upgrade codes are identical throughout, so I can't imagine how
it could not find the rela
I don't think that is the normal command for a silent install of an MSI, I
would expect something like "msiexec /i file.msi /passive"
If you are using the MsiPackage element in the log you will see an entry
containing "Applying execute package:" and after that the msiexec command line.
Neil
--
I'm confused about: if I schedule the remove existing product early like our
other installer then during that action the install fails as the dll is gone
when the custom action to InstallUtil.dll gets called. If you schedule it
afterInstallValidate or afterInstallInitialize, the old product is
Hello,
I have a problem with an older install that we have restructured to
conform to the single file per component rules. However inside of this
installer is some custom actions that call the InstallUtil.exe to install some
performance counters that we have in a dll that gets installed
Upgrades don't work like that, and neither do transacted installs.
Look for FindRelatedProducts in the verbose log and see if it's finding the
older product to upgrade. Bottom line: if you have two entries in Add/Remove
Programs then your upgrade is not an upgrade, it's side-by-side, and nothing
Hello guys,
I am new to WiX, I just created a Managed Bootstrapper project using WPF,
everything works fine except that I want to programmatically access a file
(EULA.htm) that I referenced in the Bundle.wxs as a Payload, so when the user
clicks a button it opens the EULA.
How can I acces
I am trying to display a string in the welcome page that contains something like
Company(c) My Product Name(tm)
In the localization file, this is written as:
Company© My Product Name™
Using Codepage=1252 (or Windows-1252) allows me to display the copyright
symbol, but the trademark symbol cause
Yeah, when running the MSIs, they run with the exact same command as the burn
EXEs:
cmd /c start MyInstaller.[exe or msi] -quiet -norestart -log MyInstaller.log
The only burn log lines I've found that seem to have command-line-like
parameters associated with the MSI are these:
When upgrading 1
Okay, found the element and attribute (thanks!), but I'm not sure I understand
what it does, or how it might be useful in my case, because our software
already downloads the most recent version automatically and runs it,
so...there's no point to look to a URL for an update.
Oh, although this co
Classification: Public
This is from the Bundle.wxs for the WIX 3.7 install that is provided in the WIX
3.7 source that you can download:
Check the two elements:
UpdateUrl
Update
-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: June-04-13 11
For some reason the online help doesn't mention it but it is in the help file,
go to the index and look for "Update Element".
This is only a reference to the URL, you have to write the code to handle it.
Neil
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: 04 June
One difference is that burn will only run the execute install sequence as it is
running the MSI silently, when you run just the MSIs have you tried running
them silently to see if you get the same issue - you can see the command line
that burn is using in the log files.
I had the service issue
There's a Burn Update element? Uh oh. Maybe this is part of the problems I'm
having with my bundle upgrades.
I can't seem to find such an element though. The closest I've come is this:
http://wix.sourceforge.net/manual-wix3/wix_xsd_upgrade.htm
But that doesn't seem right, because the parents ar
Yes, I have 4 ServiceControl elements in the MSI, but up until this issue came
up, the MSI had absolutely no problems stopping all the services, removing
them, and then installing the new versions, and starting them. But that was
before I was using burn...so I just tried the same process (instal
Classification: Public
What about the Burn Update element?
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: June-04-13 11:00 AM
To: 'Paul F Brewster'; 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] [WIX-users] Asking a website about the
I would like to build a multi-language installer for my App which is currently
available in English and German.
I will make the English Installer default and use a transform for the German
Installer.
Instead of the Regional Settings automatically deciding the language of the
installer, would it
For both the 1.0.1 and 1.0.2 upgrades, FindRelatedProducts = 1, ALLUSERS = 1
(which is correct), and the UpgradeCodes are definitely static and the same.
You right that all bets are off, but I think the Upgrade is "failing" because
1.0.2 can't uninstall 1.0.1 because it thinks that some files we
I probably re-invented the wheel, and not very well. Let the deployment experts
here be the judge. :-)
When our software starts up, it sends its version number to our server, which
compares that to the current version (stored in a database). If there's a
mismatch, it sends our client a link whe
Alain
It's the former rather than the later. Is there a current standardized
protocol that you use within your own software to make that check at
startup? I'm trying to use best practices and not re-invent the wheel.
This may not be a real WiX question but since this forum deals with software
dep
Are you looking for updates to your own software that the user is installing,
or third-party software (like the Java Runtime Environment)?
We do the former in our software (not WiX) at startup, not in WiX. For the
latter, we just bundle the current version with our own software installer
using
Microsoft providing Fixit tool to uninstall the error setups. Check here
http://support.microsoft.com/mats/program_install_and_uninstall/ .
-Original Message-
From: Chaitanya Sanapala [PC-BLR-DEV] [mailto:chaita...@pointcross.com]
Sent: Monday, June 03, 2013 7:59 PM
To: WiX-users@lists.s
Yes exactly, in my main bundle's UX I want to display some MSI progress
messages during long running operations.
If it was implemented in the engine itself it would be nice, but as I have
control over all used bundles I could also implement it on my own if the method
SendEmbeddedMessage would e
34 matches
Mail list logo
