You need to copy WixUI_InstallDir.wxs into your project (I recommend to keep
the fragment in a separate file for better modularization, but it's not a
requirement). Change the Id attribute of the UI element to a random name and
also change your UIRef accordingly.
Then you are free to change
I assume you have some nifty tool to do this?
I like the style of the CHM documentation very much, so I would like to
create my own CHMs from XSDs in this way...
Thanks
--
View this message in context:
Arnson-6 wrote:
zett42 wrote:
I get a warning from Candle about my CAB file names not following 8.3
format.
Check the MSI SDK: it says cabinets must be 8.3 name.
--
sig://boB
http://joyofsetup.com
I get a warning from Candle about my CAB file names not following 8.3 format.
Though the installation seems to run fine.
Has anybody got a problem from using long CAB names or otherwise know why
they should be avoided?
--
View this message in context:
Seems to me like a timing issue. I think the cancel command will not be
processed until your custom action returns. Then Windows Installer might
decide that it is too late to cancel immediately before / during
InstallFinalize.
I would try to call MsiProcessMessage() at the end of your CA. If
of the stuff a Feature can contain. Just define a
FeatureGroup with only MergeRef elements in it.
zett42 wrote:
Yeah, I could live with it. But it doesn't feel right to create an
artificial
feature just for grouping merge modules. It is not intuitive for WiX
beginners I think.
Rob
Sorry, I just noticed that FeatureGroup is already listed as possible
parent of MergeRef, where it really belongs to :)
zett42 wrote:
Thank you for this hint. Then there is indeed no need for MergeGroup. It
might help to add FeatureGroup to the list of possible parents of the
Merge element
be okay, right?
Bob Arnson wrote:
zett42 wrote:
So would it make sense to add new elements MergeGroup and
MergeGroupRef
Sure, feel free to file a feature request.
--
sig://boB
http://joyofsetup.com
Disclaimer
-Original Message-
From: zett42 [mailto:sa...@gmx.de]
Sent: 20 May 2009 13:37
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] MergeGroup / MergeGroupRef
Yeah, I could live with it. But it doesn't feel right to create an
artificial feature just for grouping
For getting the disk-space per drive you would have to use
MsiEnumComponentCosts().
You would write an immediate-mode custom action to call this function and
then MsiSetProperty() to set your properties.
Mark Sinnathamby wrote:
Hi,
I have a custom dialog during installation where I have to
cl.exe do in this case?
zett42 wrote:
I have a directory structure for my source files like this:
main.wxs
subProduct\main.wxs
When compiling, the created .wixobj files overwrite each other, because
candle puts all files into the same directory.
My current workaround is to call candle once
Define ARPSYSTEMCOMPONENT and create your own uninstall registry key. There
you can set the path to your EXE that will be called by Windows for
uninstall.
There are some issues with patches though:
http://blogs.msdn.com/heaths/archive/2005/08/05/the-dangers-of-arpsystemcomponent.aspx
ron
When compiling multiple MSIs with different names from the same MSBuild
script, only the last compiled MSI survives.
Is there something I can do in my main MSBuild script to prevent the WiX
MSBuild script from deleting the previously build MSI file?
A comment in wix.targets says:
Andrew Kendall-2 wrote:
Given that no dialogs appear for a client install, how do you control what
gets installed? Is there some default value for each button/checkbox that
the user is not seeing!?
For a per-machine installation via group policies, only the
InstallExecuteSequence is run.
Robert O'Brien-2 wrote:
Question - is the reason for sequencing the execution of a customaction in
both InstallUISequence And InstallExecuteSequence so that you cover both
interactive and unattended installs?
Exactly.
Robert O'Brien-2 wrote:
In the case of an interactive install do
Correction: By default a CA is run twice if you put it in both sequences and
UILevel is NOT basic NOR silent.
;)
zett42 wrote:
Robert O'Brien-2 wrote:
Question - is the reason for sequencing the execution of a customaction
in both InstallUISequence And InstallExecuteSequence so
I have the following registry searches, the 1st one fails on _some_ machines,
the 2nd works as expected.
Property Id=MY_EXISTING_TARGETDIR Secure=yes
RegistrySearch Id=TargetDirSearch Root=HKLM
http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx
Under Feature and component state values.
I think it could work if you put LaunchConditions after CostFinalize in the
sequence tables.
Otherwise, you could also use a CustomAction using the Error attribute and
you could sequence this
What is the usual way to self-uninstall a bootstrapper EXE?
Our bootstrapper EXE is installed into the program directory where it is
called from ARP to provide the same UI experience as during first
installation.
To my surprise, Windows Installer seems to have some magic to uninstall the
EXE
Because the files are non-versioned, MSI treats them as user-files and does
not reinstall them if they are modified.
See http://msdn.microsoft.com/en-us/library/aa368599(VS.85).aspx
Raj P wrote:
Hi,
The current problem, that I am fighting with is
I have an msi which has simple UI
You need a deferred custom action with no impersonation scheduled in the
InstallExecuteSequence after the standard action InstallInitialize to make
sure the CA is always run with system privileges (if you really need that).
You are also forced to per-machine installation then.
MadhaviAthota
I don't really see how companion files would help in this situation.
Alexander Shevchuk wrote:
You may want to use Companion files
(http://msdn.microsoft.com/en-us/library/aa367997(VS.85).aspx) in this
situation.
-Original Message-
From: zett42 [mailto:[EMAIL PROTECTED
to give you options to consider.
-Original Message-
From: zett42 [mailto:[EMAIL PROTECTED]
Sent: Friday, November 07, 2008 01:53
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Upgrade problems when using directory as keypath
Wouldn't Windows Installer then want
as the keypath file.
Rob Mensching-2 wrote:
If you have a dummy file that has a version resource in it, you can
companion all of the non-versioned files to the dummy file and implicitly
provide them a version. It may work out well.
-Original Message-
From: zett42 [mailto:[EMAIL
I'm using the scheme described at MSDN
(http://msdn.microsoft.com/en-us/library/aa368269(VS.85).aspx) to organize
my setup into components.
Given a single directory, all files without version information (e.g. *.jpg,
etc.) are grouped together into a single component which has the directory
as
explicitly marking the Component Directory
as the KeyPath?
-Original Message-
From: zett42 [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 06, 2008 10:08
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Upgrade problems when using directory as keypath
I'm using the scheme
Rob Mensching-2 wrote:
1. The Windows Installer evaluates the KeyPaths when deciding to repair
existing installed Components. If you use a Directory as the KeyPath then
the Directory just has to exist for the Component to skip being repaired.
There are lots of variables in this that can
27 matches
Mail list logo
