Thanks for all the replies.
I'd solved it by removing the Feature entirely using a Condition for
the Component after adding the Component to the main Feature.
Component Id=RibbitLink Guid=myguid
Condition![CDATA[LINKTORIBBIT = True]]/Condition
IniFile Id=RibbitIniMod Action=addLine
For our installation we have a lot of custom actions being called, all the
post-install ones are chain-schedualed after InstallFinalize
eg CA_Cust1 After InstallFinalize, CA_Cust2 after CA_Cust1. They are in the
InstallExecuteSequence with NOT INSTALLED AND NOT REINSTALL as the condition
and
Bob,
I guess I still need to learn more about Windows Installer...
It was my understanding that formatted text expansion would typically
occur before the user interface is shown. In this specific case, the
user conducting the installation will be modifying the values, hence the
reason why
When running our MSI package on Vista midway under the installation a dialog
pops up (UAC) and complains about Unknown Publisher on our package.MSI
file and asks for permission to continue. Is there anyway to author our
package in such a way that the user won't be bothered with such
Hi All,
I am a newbie to WIX, but I am using Installshield. Now I need to port my
installers to WIX. In Installshield while doing Dynamic File Linking option
I will be getting a option like, I can select only required files from that
directory. That means for example I can select only *.aspx
Hi All,
WiX v.2.0.4280.0
I have a confusing problem that I haven't been able to solve with my limited
WiX / MSI experience.
I am creating an installer that has a UI that allows the user to enter some
values. These values are subsequently used in a custom action as part of
the actual
Sign your MSI.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pseudonymic
Wannabe
Sent: Tuesday, May 29, 2007 6:05 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Vista unknown publisher
When running our MSI package on Vista midway under
1. No. You can use 32-bit CustomActions in a 64-bit package.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cosmin Manoliu
Sent: Monday, May 28, 2007 12:13 AM
To: WiX-users@lists.sourceforge.net
Subject: Re: [WiX-users] Wix Extension useable for 64 and
2. The files are installed in the order specified by the Sequence column. The
WiX toolset manages the Sequence column for you because the order should not
matter. The control you get is that you can control the order of groups of
files because the Media element specify the order of each
Brand New AMERICAN REAL ESTATE AGENTS Database
1,050,902 Total Records
85,658 Emails
Fresh data just compiled this week - never before sold.
Regular price is $499
\
\\\SPECIAL PRICE UNTIL June 1st\\\
\\\ONLY $299!\\
[sorry, accidentally hit ctrl+enter]
1. There is only a portion of light.exe that does major file IO. If you
cannot get an exception for some of your build drives with your antivirus
software then you are going to be suffering with performance issues there.
Seriously, I have seen 300%
2. 15 minutes to copy 3-4 GB isn't bad too. Remember, the WiX toolset is
going to lay out your full DVD image in the way that the Windows Installer
expects to see it. Compression obviously takes more processing. Also, with
file IO much of the time will be counted against the operating
Hi All,
I'm still trying to port from InstallShield to wix, and here's the
problem I'm running into: The user enters an authorization key, which
is checked for validity in a CA. The CA also determines which features
are available based on this key, and I want to disable the features that
Couldn't one set the environment variable WIX_TEMP to somewhere in the
build area therefore only have to exclude one area from AV on-demand
access?
I would personally be wary of excluding the entire TEMP directory,
whether it be on the user profile or the build machine's Windows
directory unless
I had a similar situation last week recieved a grand total of 1
replies. I've come to the conclusion that using Condition to set the
Level of a Feature doesn't work (at all, as in it's a bug).
I tried to use it to set the Feature Level to either 1001 or 1 (1001
would exclude it from any install
Yes, when I say temp directory, I mean wherever you have your temp directory
pointing. WIX_TEMP is a great way to use a custom temp location.
-Original Message-
From: Pally Sandher [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 29, 2007 9:30 AM
To: Rob Mensching; Igor Maslov
Cc:
Just want to point out that even if you sign your MSI, you will still
get a Unknown Publisher on uninstallation.
It's sort of a sad limitation that is explained here:
http://blogs.msdn.com/windows_installer_team/archive/2006/10/19/new-wind
Pseudonymic Wannabe wrote:
For our installation we have a lot of custom actions being called, all
the post-install ones are chain-schedualed after InstallFinalize
As an aside: That's outside the install transaction, so you can leave
the machine in a bad state if any custom action fails.
NOT
[EMAIL PROTECTED] wrote:
It was my understanding that formatted text expansion would typically
occur before the user interface is shown. In this specific case, the
user conducting the installation will be modifying the values, hence
the reason why I (and apparently Rennie also) believed a
Rik wrote:
I am creating an installer that has a UI that allows the user to enter
some values. These values are subsequently used in a custom action as
part of the actual installation.
Properties must be public (i.e., named in all UPPERCASE) and secure
(@Secure=yes) to be passed from the
hariom wrote:
directory. That means for example I can select only *.aspx files OR *.dll
from particular directory. Is that this feature is available in WIX also?
No. It's been discussed on the list many times (search the archives for
the fun). You can use the heat tool in WiX v3 or tallow
I use this very successfully actually and have not had any problems with
it. My feature declaration looks like this:
Feature Id=MyFeature Title=My Application Feature Display=hidden
Level=1 ConfigurableDirectory=INSTALLDIR AllowAdvertise=no
ComponentRef Id=MyInstallComponent /
Condition
You can do it, but not in the way you describe.
Component Id=MyComponent Guid=12345678----ABCDEF00
File Id=FirstFile Name=foo.bar Keypath=yes
Source=C:\sample\foo.bar /
File Id=SecondFile Name=foo2.bar Source=C:\sample\foo2.bar /
File Id=ThirdFile Name=foo3.bar
Hi,
My Error Dialog is as follows:
Dialog Id =ErrorDialog Width=370 Height= 100 Title=
[ProductName] ErrorDialog =yes
Control Type =Text Width= 123 Height= 17 X =20 Y
=10 Id =text1
Text ![CDATA[{\VSI_Arial16.0_1_0}Install Unsucessful! ]]/ Text
/Control
Hi All,
Thanks for the reply, but that doesn't do it for me. If I use this
code, all of the features are disabled since none of the property values
are set initially. As a reminder, I set property values in a CA called
from a UI before the CustomizeDlg is called. Since I can't seem to
Feature
That fixed it, thanks Bob.
As a comment:
Isn't it unusual convention to have the case of a name dictating the
protection level? I guess that's a legacy thing from MSI, rather than a
feature of WiX..?
On 29/05/07, Bob Arnson [EMAIL PROTECTED] wrote:
Rik wrote:
I am creating an installer that
I might have sent my reply to the wrong address earlier. Apologies if it
double-posts...
Hi hariom,
I'm using WiX v2.0.
I managed to achieve what you're looking for by using tallow.exe with
msbuild. In fact I wrote a custom task that calls the tallow executable and
parses and re-formats the
Hi,
I got the desired effect by including the contents of ErrorDlg.wxs file in my
WXS file and modifying the Text attribute as follows
Control Id=O Type=PushButton X=100 Y=65 Width=56 Height=17
TabSkip=yes Text=amp;Close
Please let me know if this approach is a good practice.
Thanks,
You may be able to build your ADDLOCAL property from checkboxes instead of
using the Feature Selection dialog. This would allow you to enable or
disable the checkboxes based on property values.
The problem you are having is a sequencing problem. The feature conditions
have already been
Yeah, it's an MSI thing. Goofy? Agreed.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rik
Sent: Tuesday, May 29, 2007 12:25 PM
To: Bob Arnson
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Help with Properties set in a UI then used in a Custom
Action
That fixed
I've got the same error trying to build my WiX (Votive) setup project as part
of my Team Build.
light.exe(0,0): error LGHT0216: An unexpected Win32 exception with error
code 0x659 occurred: This installation is forbidden by system policy.
Contact your system administrator.
The project builds
I figured out how to specify -sval using Votive.
0. Check out your Votive setup project from source control
1. Right click on your Votive setup project
2. Click on Linker
3. Select the Configuration for which you want to specify -sval
4. Click Advanced...
5. On the Light Advanced Settings
I am mainly concerned with how I reference multiple extensions. Is it like
the following?
candle
...
extensions=${Wix_path} name=WixNetFxExtension.dll
;WixIIsExtension.dll;WixSqlExtension.dll;WixUIExtension.dll;WixUtilExtension.dll
...
/candle
Is this even supported? You know all those
Where can I find information on the difference between WiX 2.0 and WiX
3.0?
I'm planning on upgrading to 3.0 and would like to know all the things
that I can take advantage of over 2.0.
-
This SF.net email is sponsored
That level of control isn't possible in a merge module. Provide an .msi
package instead.
So, what's the point of merge modules then? If I can't distribute a
third party library that other people can use as a dependency, what good
are they for?
And I don't think one can reasonable say it can
35 matches
Mail list logo
