Hi, I am using the WiX-only approach described in the wix3 chm to create patch
packages. In some cases lots of extra files (files that have not changed from
the baseline version) are being included in the patch, maybe hundreds. They are
not referenced in the patch.wxs file, and I have no idea ho
I will try that.
However, the sole reason for my using MSPATCHC.DLL 6.0 was because PatchWiz.dll
version before 4.0 had other patching problems which were reported to be solved
by PatchWiz.dll version 4.0 and above. So I used SDK 6.0 version of
PatchWiz.dll which is 4.0 and it comes with 6.0 v
Hi Blair,
I really appreciate your efforts on this issue.
Yes, "how maintenance-mode UI is supposed to work?" - This is the question I'd
ask.
So anyone, if you happen to know "how maintenance-mode UI is supposed to work"
or any useful link as you know of, please let me know.
Thanks you all!
So it looks like Amy's multiple products all have the same UpgradeCode,
different ProductCodes.
If they also all have the same ProductVersion then there's no way to
distinguish one from another in the Upgrade table. The kind of thing needed is
either:
a) Multiple upgrade codes for the instal
Hi,
I have created a custom dialog that executes during my installation where the
user selects the environment (TEST, QA, or PROD) that they are installing into
via a radio button, and this radio button is bound to a property in my
installer. I would like to update some other properties in my
Alternately try building with version 5.1 of MSPATCHC.DLL (by building on an
XP box?).
-Original Message-
From: Tony Juricic [mailto:tjuri...@tradestation.com]
Sent: Wednesday, September 02, 2009 1:36 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Pa
I tried installing Windows Installer version 4.5 on XP machine but that didn't
fix the problem.
What fixed it is quite scary because of the hacky method that was used.
In short, copying Vista version 6.0 of MSPATCHA.DLL (from System32 folder) to
XP, which had version 5.1 of it, made patching su
I am not sure what you mean by "have MigrateFeatureStates set in the
Upgrade entry for only that product you want to migrate the features
from".
I have the following for my upgrade xml:
To be clear about how I am making all this work, I have embedded
transforms of the product
MigrateFeatureStates checks records in the Upgrade table. It completely
ignores your OLDAPPFOUND property. This property is just for use in conditions.
Also, keep in mind that usage of MigrateFeatureState is limited
(http://msdn.microsoft.com/en-us/library/aa370034(VS.85).aspx):
"... The metho
There's no connection between the property you put in your Upgrade entries and
what actually happens. I'm really very sure that OLDAPPFOUND is for your
information only - it doesn't drive anything, so changing it won't affect
anything.
What you need to arrange is as previously suggested, have
It wasn't obvious to me that the PageCountSummary property is the same as the
packa...@installerversion property. I admit I am new to WiX, but I think it
might be beneficial if there were a more direct linking between the two
properties, or at least the documentation for the two properties.
St
http://www.tramontana.co.hu/wix/lesson8.php#8.6
search the archives
-Original Message-
From: Radhakrishnan Meiappan [mailto:rmeiap...@datacert.com]
Sent: Wednesday, September 02, 2009 11:54 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Starting ano
OK, so now I have MigrateFeatureStates actually doing something.
However, it is still attempting to migrate the features states from all
of the installed instances of my application. The property listed in my
Upgrade table to use for storing the product codes to upgrade is
OLDAPPFOUND. The action
Thanks. I can't find the 'launch after install' pattern in the tutorial
nor in the user-list archive.
Can you send me the url to either one of those.
RK Meiappan
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Wednesday, September 02, 2009 1:14 PM
To: 'General discussion
I'm re-authoring them from scratch. Currently the merge modules are just a
small collection of file components, one of them being the service exe that
needs to be registered. The service component looks like so:
Blair-2 wrote:
>
> How that is done really depends on the merge module. W
These installers are still for your office? Do you always distribute them in
such a fashion as to have UI from the MSIs shown to the user? If so, you
could try adapting the "launch after install" pattern mentioned in the
tutorial and this list.
-Original Message-
From: Radhakrishnan Meiapp
How that is done really depends on the merge module. Who wrote those?
-Original Message-
From: NateBank [mailto:etherw...@gmail.com]
Sent: Wednesday, September 02, 2009 11:02 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Setting account info in merge module from MSI dialog
I'm cutting my teeth on WiX 3 by converting an InstallShield MSI to a proper
MSI, and I'm running into a problem with the services merge modules. I have
three services, each with their own merge module, that need to be registered
with a domain account. I have not been able to figure out how to g
We use wix to create installers for our product in our office.
Now, I have to call or trigger another third party installer (an .exe
file) after my wix installer has finished installing.
Are there any hooks in wix that will let me do something like that ?
Any advise that will point me
Done: #2849248.
Is it possible to be fixed for WiX 3.0 as a hotfix for the released
version?
I'm not sure it is a good idea to switch to unstable 3.5 for
production...
Or, as a alternative, can you please attach a patch that fixes this to
the artifact? I can then have my custom build based on 3.
I believe it also controls the default bit-ness for the "Win64" attribute on
certain things like RegistrySearches, Components, and binary Custom Actions (if
you specify a 64-bit architecture, these will default to 64-bit).
To see where it's used in the code, I'd open src\wix\compiler.cs and sear
I am able to reproduce your failure - I haven't investigated in detail yet, but
it could be a bug. Go ahead and file a bug on SF against WiX 3.5, and attach
your repro authoring to the bug.
Thanks,
Mike Carlson
-Original Message-
From: Yan Sklyarenko [mailto:y...@sitecore.net]
Sent: We
Thanks Blair!
I tried your method that adding Name attribute to . And it works!
My OS is Windows XP Professional. I don't know if it is 64-bit or not. What is
32-bit MSI?
Regards,
Chunyan
-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com]
Gesendet: Mittwoch, 2. September
Rob's latest blog refers to the -arch option for candle. I can't find
any documentation for what that does example. It apparently implicitly
sets the Package/@Platform. What else does it do? I tried following it
in the code, but got lost pretty quick.
My project uses $(var.Platform) in Package/@De
One option would be to try:
SYBASE_10INSTALLATION
But, I have another question. Is this on a 64-bit OS with a 32-bit MSI?
-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Wednesday, September 02, 2009 6:45 AM
To: Gen
Hi Sebastian,
Thank you for your reply. I tried the method as you suggested. The following is
my code:
SYBASE_MAJORVERSION
However, when I install my msi, it always pops uo the warning message, saying
"MyApp requires Sybase 10.0. Please make sure it is installed." I
Hi Mike,
I've managed to localize the problem. This looks like a bug in WiX IIS
extension to me. Here's the description.
I have several components, each contains a iis:WebSite element. This way
I specify different settings for IIS 5, 6 and 7 web sites. Each website
has the iis:WebDir element insi
I am using PatchWiz.
Also, I am afraid I don't understand if I should use IgnoreRange, if I could do
it with PatchWiz.
On XP the patching system thinks that file has been already patched which is
simply wrong, even if the difference is probably only in version resource part
of the file. It a
28 matches
Mail list logo
