Actually, after a couple hours more searching around i finally
stumbled across this bug report:
http://sourceforge.net/tracker/index.php?func=detail&aid=3013386&group_id=105970&atid=642714
I've spent so many years training myself that "Win64=yes" was for x64
builds and "Win64=no" was for 32-bit b
> Running 32 bit apps in a 32 bit shell is a great idea, but it seems less than
> ideal
> that it excludes all possibility of viewing the registry as it "really" is.
My point is that the operating system provides a 32-bit view for 32-bit
applications since they only know of the 32-bit world. A 3
Setting an extra 32-bit registry value is definitely a good idea,
unfortunately we've already shipped the main program, so it's a little
late for us to add it :(
Running 32 bit apps in a 32 bit shell is a great idea, but it seems
less than ideal that it excludes all possibility of viewing the
regi
Windows (the OS) will redirect 32-bit apps in such a way that they can't tell
that they are executing on a 64-bit OS. The 32-bit app will blissfully execute
as if it was in fact executing on a 32-bit OS as it was designed to do.
A 32-bit Windows Installer package is executed in a similar context
We actually already have two different installers. However the problem
is that we need to account for the possibility that they've installed
an x64 version of the main program on an x64 machine, and then try to
install the x86 version of the utility on the same machine. So the x86
installer needs t
I believe you need to issue two different installers and set the Win64
attribute for each RegistrySearch element.
You should not specify the Wow3264Node in the path.
If you need to do this in a single installer, you will need to condition the
search so that it only triggers for the appropriate OS
Don't confuse "AppSearch worked fine" with "AppSearch did or didn't find my
file", not to mention that AppSearch could be searching for multiple items, and
not all of them files.
The indicator is whether the property is set or not. When I look at verbose
logs for AppSearch I see an explicit en
Hello,
I am having an issue when I attempt a conditional file installation
based on a folder being present. Currently I have the following:
FILEEXISTS
Unfortunately, the installer always defaults to '1'. At the same
time it also does the following:
AppSearch: Proper
Hi,
I have created an installer using wix and when the user installs our
product, I set it to be installed for ALLUSERS by setting ALLUSERS
property to '1' as follows.
However, on certain windows when I call MsiGetProductInfo(), it
returns '1605' - This action is only valid for products that are
Hello WiX list.
I would like to know if there is any way to change the Dialog's subtitle
font color independently from the text in the content of a dialog.
Scenario is: I have two background images, one for first and last screen and
one for dialogs in the middle. The one for dialogs does not get
We're trying to do a couple registry searches at the beginning of a
utility installation to check for the existence of our main product so
we can take certain actions. Everything works fine when using the x64
installer on an x64 machine, but when we try the x86 installer all
the registry checks fa
You should post the verbose log somewhere. You won't see errors if it thinks
it's doing the right thing (which is not the same as what you want it to do).
Phil Wilson
-Original Message-
From: Jacob, Marcus [mailto:mja...@toptechnologies.de]
Sent: Monday, April 04, 2011 7:26 AM
To: Gen
The registration process is not the problem. The self-reg works fine if the
file is available but the installer does not copy the file.
Von: Pally Sandher [pally.sand...@iesve.com]
Gesendet: Montag, 4. April 2011 11:56
Bis: General discussion for Windows In
How about not using self-reg & harvesting the registration info from
richtx32.ocx using heat.exe?
That works perfectly fine for me on all OS from XP onwards.
Palbinder SandherÂ
Software Deployment Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulat
Michael:
I did create a log file, but it has no errors. It seems, as if the component is
just beeing ignored.
Peter:
There is no entry from WFP. It would by the way would make no sense if there
was one, since everything is working fine as soon as I copy a text file along
with my ocx...
_
Check the event log to see if there are any messages where Source = Windows
File Protection. If so, have a look here
http://support.microsoft.com/kb/222193
-Original Message-
From: Michael Tissington [mailto:michael_tissing...@ciqual.com]
Sent: 04 April 2011 09:05
To: 'General discussion
Have you tried running the msi with logging enabled and see what you get in
the log?
Msiexec /I package.msi /l*v log.txt
-Original Message-
From: Jacob, Marcus [mailto:mja...@toptechnologies.de]
Sent: 04 April 2011 08:55
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Why does m
My WiX (3.5) installer should copy the richtx32.ocx file to the
windows\system32 dir and register it by using some command line statements but
it does not work. The file is not copied to the folder.
The problem occurs on XP and also on Win7 and yes, I have started the M
18 matches
Mail list logo
