Hi,
When the Platforms property of the Package tag is set to x64, the built package
becomes 64-bit-only and will not install on 32-bit Windows.
Is there a way to do the reverse, i.e. disallowing a 32-bit-only package to be
installed on 64-bit Windows? This is because we have two versions for
Why would you want to? a 64bit computer can run 32bit applications it
just can't be done the other way around hence the restriction. If you
must you might might have to do the detection and blocking yourself.
Dieter Lunn
http://www.coder2000.ca
On Mon, Nov 9, 2009 at 3:01 AM, Lukhnos D. Liu
Adding tags like these should do it:
UI
Error Id=25000Please use the 64-bit installer/Error
/UI
CustomAction Id=Need64BitVersion Error=2001 /
InstallUISequence
Custom Action=Need64BitVersion Before=AppSearchVersionNT64/Custom
/InstallUISequence
Rob
Lukhnos D. Liu wrote:
Hi,
When
Hi there
Since ClickThrough is not ready yet, can anyone suggest what other
alternatives are available?
I googled some third party software that seem to handle auto upgrade but
I'm not sure how well they work.
http://www.catenalogic.com/products/updater/information
Dieter if you read Luknos' e-mail you should see the reason why he would
like to disallow installing the x86 package on x64 platforms (see 3rd
sentence).
Rob Hampflett already posted one solution but a simpler way to achieve
this would be to add a Condition element inside your Product Element to
2 ways to achieve it off the top of my head.
1 - Easy way, use the Major Upgrade functionality. See the How To at
http://wix.sourceforge.net/manual-wix3/major_upgrade.htm (also in the
WiX.chm). This requires the original MSI created in WISE to have an
UpgradeCode set in it. Having never used WISE
Hi all,
I have the following problem with our installer for which we deliver a service
pack (patch) setup.
We use for the setup and patch build the WiX build 3.0.4014.0.
Situation is as follows:
a) we built (and shipped) our product MSI (let's call it build 1.0).
b) we built (and shipped) a full
Hi Rob,
thank you for the hint, it has solved my problem.
My condition for the UI now uses the action state of the feature and
replaces '' with 'amp;'. Then it works fine:
Condition Action=showamp;Feature2=3/Condition
Thomas
Rob Mensching-7 wrote:
I think you need a or ! before the
Create a LaunchCondition by placing the following element under your Program
element (anytime after the Package element):
Condition Message=Requires 32-bit Windows. Use our 64-bit package on this
platformNOT VersionNT64/Condition
-Original Message-
From: Lukhnos D. Liu
If you do any of these three things:
1) use either the C/C++ runtime MSMs
2) install drivers using Difxapp
3) install stuff using either GAC or WinSxS (that is: if any of your File
elements contain an Assembly attribute set to anything except no)
then there are upgrade scenarios (even with major
Perchance did you remove any components in your SP2 patch?
Set MSIENFORCEUPGRADECOMPONENTRULES=1 in both commandlines when rerunning
the scenario. If you get an installation failure that should point you to at
least one component rule violation that will produce the effect you are
describing.
I was just curious if there was an easier way of installing PDBs? What I have
works, but it seems cumbersome.
Component Id='c_AppServer.DTO' Guid='...'
File Id='f.AppServer.DTO'
Name='$(var.Application.ApplicationServer.DTO.TargetFileName)'
Hi there,
I am using setupbld to create a setup.exe from my msi. Using the command:
SETUPBLD -title MyApp -ms MyAppSetup.msi -setup setup.exe -out MyAppSetup.exe
However, I get a strange difference between the exe msi installer version.
Running the installer with the application already
Hi there,
I am using setupbld to create a setup.exe from my msi. Using the command:
SETUPBLD -title MyApp -ms MyAppSetup.msi -setup setup.exe -out MyAppSetup.exe
However, I get a strange difference between the exe msi installer version.
Running the installer with the application already
or more simply the setup.exe version just goes straight to Resuming install..
instead of Welcome to install ?
From: warne...@hotmail.com
To: wix-users@lists.sourceforge.net
Subject: setupbld setup.exe repair install
Date: Mon, 9 Nov 2009 15:57:31 +
Hi there,
I am using setupbld to
Алексей Далекин wrote:
I'm using WIX v3 to install my filter driver. The driver is installed
correctly but DeleteFiles option doesn't work.
You'd have to take that up with the DifxApp folks; WiX just wraps their
custom actions.
I need to remove *.inf, *.sys files from my InstallFolder
Adrian Gantoi wrote:
The installation was successful, even with MSIENFORCEUPGRADECOMPONENTRULES=1.
Search the log for SELMGR.
--
sig://boB
http://joyofsetup.com/
--
Let Crystal Reports handle the reporting -
Dan Giambalvo wrote:
So, is there any way to work around this issue? Is there something I can do
in the handler of my button to cause a focus change before I invoke my CA?
I'm not aware of any.
--
sig://boB
http://joyofsetup.com/
Ok, that's much better.
-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com]
Sent: Monday, November 09, 2009 10:16 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Installing PDBs
John H. Bergman (XPedient Technologies) wrote:
I was just
Thanks Blair.
After removed those curly braces, it works.
I'll log a bug.
Thanks again.
From: Blair os...@live.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Friday, November 6, 2009 6:56:44 PM
Subject:
Maybe this is not a great place to ask, but if you know -
I wonder if there is a way to install the .NET 3.5 framework by showing
non-English language on GUI. Is it possible?
I tried dotnetfx35setup.exe /lang:FRA, but it still shows English.
Thanks.
From:
Version 3.0 (final version) will not allow DllSurrogate= on the AppId.
It says that if I want an empty string to remove the attribute.
Current build of 3.5 will allow DllSurrogate=.
If the attribute is removed, there is no entry in the Registry table for
the DllSurrogate value and that is not
I have the following XML
Component Id=COMDllComponent
Guid=FE540942-A911-4bc3-851C-1A810122011E
File Id=COMDll Name=$(var.COMDll.TargetFileName)
Source=$(var.COMDll.TargetPath)
Assembly=.net AssemblyApplication=COMUser
AssemblyManifest=COMDll
DiskId=1 KeyPath=yes /
AppId
The setup executable that I am building with setupbld using the setup.exe
stub crashes with a The process terminated unexpectedly message box. The
install requires a reboot, so the ScheduleReboot action is called. The
crash occurs after the reboot dialog is cleared. It does not matter how the
Note: I forgot to mention that I removed the ScheduleReboot and I did not get
the error message.
John L Krupka wrote:
The setup executable that I am building with setupbld using the setup.exe
stub crashes with a The process terminated unexpectedly message box.
The install requires a
Hello,
I've seen multiple similar posts but none seemed quite what I was looking
for, sorry if this has already been answered.
We have released one MSI for each language we support - each with it's own
ProductCode and CodePage.
Using Wix only patching, I thought it should be possible to
Looking at the 3.0 RTM help chm, here is what I see:
Try removing RelativePath attribute entirely from the Class element.
-Original Message-
From: Roy Chastain [mailto:r...@roychastain.org]
Sent: Monday, November 09, 2009 12:52 PM
To: General discussion for Windows Installer XML
The safest way requires that you prepare both admin images and call torch
twice, once for the English old against the English new and the other time
for the Spanish old and Spanish new. You then need to supply both wixmst
files to pyro by supplying the -t argument twice. This means you will be
Bob Arnson wrote:
Search the log for SELMGR.
The log files do not contain it...
From: Adrian Gantoi gantoiadr...@yahoo.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Mon, November 9, 2009 5:14:48 PM
29 matches
Mail list logo
