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 everyt
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:
http://n2.nabble.com/How-does-the-WiX-team-generate-wix.chm-from-wix.xsd--tp3189821p3189821.h
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.
>
> --
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
Msi
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:
http://n2.nabble.com/Long-CAB-file-name-tp2
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"
ned. A FeatureGroup
> contains all 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
d. Registered in Scotland No.
> SC151456
> Registered Office - Helix Building, West Of Scotland Science Park,
> Glasgow G20 0SP
> Email Disclaimer
>
>
>
> -Original Message-
> From: zett42 [mailto:sa...@gmx.de]
> Sent: 20 May 2009 13:37
> To: wix-users@li
but that should be okay, right?
>
> Bob Arnson wrote:
>> zett42 wrote:
>>
>>> So would it make sense to add new elements "MergeGroup" and
>>> "MergeGroupRef"
>>>
>>>
&g
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 t
I noticed that it is currently not possible to reference a group of merge
modules (e. g. VC++ runtimes) which are defined in another file, other than
grouping the merge modules in a feature. Than we can use to
reference the merge modules.
So would it make sense to add new elements "MergeGroup" a
;
> What does 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 file
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 for each sub directory and
specify a differe
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 cooper
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:
> Incremental
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 r
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
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 instal
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 thi
I have the following registry searches, the 1st one fails on _some_ machines,
the 2nd works as expected.
Nearly identical, except the 1st one uses Type="director
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 desp
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 wr
; we're just trying 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
n
act 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-
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-
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
f problem... so are you 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
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 its
29 matches
Mail list logo
