Hi,
We are using setupbld.exe to chain two msi and it works fine first time, but
the output integrated exe does not let us do the change mode during next
time install but goes to reinstall mode.
This is the command for chaining:
setupbld.exe -out integratedInstall.exe -msu first.msi -msu second.ms
Yes the ini needs to be left behind on rollback and uninstall. With an
uninstall it is left behind as desired.
Changing the scheduling of RemoveExistingProductsdoes not have any effect.
It just seems strange that if the major upgrade does a uninstall then a
install why should a rollback of the
I seem to have the strange need of building a preprocessor variable from
another preprocessor variable which doesn't seem to be supported (not that I am
surprised by that).
I'm trying to do:
And then elsewhere:
The idea being only the project name is the variable and the rest are resolve
Hi Phil,
How is the WIX support for MSI 4.5 features? We are planning to use Multiple
transaction features.
Are there some help resource avaiable?
Thanks
On Fri, Jan 21, 2011 at 11:17 AM, Wilson, Phil wrote:
> Use MSI 4.5 - it got restored there.
>
> http://support.microsoft.com/kb/942288
>
> P
It *was* a vbscript.dll registration issue. I followed the instructions
here http://blogs.msdn.com/b/astebner/archive/2007/06/07/3151752.aspx
(following the 64-bit bits) to fix the problem. I have no idea how the
script engine got registered at the user level, but the key was there.
Once I remove
I haven't tried it yet. I am working on a best practices internal document and
the question popped up in my head. If you haven't ran into a problem yet then
it is very likely that Windows Installer already does the right thing. I'll
keep an eye out and report back to the list if I discover other
Use MSI 4.5 - it got restored there.
http://support.microsoft.com/kb/942288
Phil Wilson
-Original Message-
From: Andy Clugston [mailto:clug...@gmail.com]
Sent: Thursday, January 20, 2011 6:35 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Custo
This is why we're always plugging use of Virtual Machines for install
testing I guess this is another plug.
Phil Wilson
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Friday, January 21, 2011 8:09 AM
To: General discussion for Windows Installer XML t
Unfortunately, MSIUSEREALADMINDETECTION requires Windows Installer 4.0.
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Friday, January 21, 2011 10:35
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Confusionm around Privileged property
P
Have you tried Component/@Win64="yes" for that component?
Not sure if that's needed if you're following robmen's advice and using
-arch, as that switch should set Win64="yes" for you (I think?)
-Original Message-
From: Manoj Jangid [mailto:jangi...@gmail.com]
Sent: 21 January 2011 16:12
Please test this and report back to the list.
http://msdn.microsoft.com/library/aa816403.aspx
-Blair
-Original Message-
From: Alex Ivanoff [mailto:alex.ivan...@shavlik.com]
Sent: Friday, January 21, 2011 7:25 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX
Hello again all,
I thought I'd start a fresh topic as I now have a new issue. I set a property
to be "1" if a feature is being installed before "InstallValidate". The log
shows this property is being set correctly. I have 2 other features that are
hinged from this property that both don't get i
apart from this error I am also getting
mypack64.wxs(7) : error CNDL0004 : The Package element contains an
unexpected attribute 'Platform'.
Manoj
On Fri, Jan 21, 2011 at 4:12 PM, Manoj Jangid wrote:
> After changing to ProgramFiles64Folder I am getting following error
>
> : error LGHT0204 : IC
Specifically, Companion Files are the only things that get written
without regard to versioning. So maybe make the default settings file a
Companion File of another feature that *will* always get installed on a
re-install?
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.c
After changing to ProgramFiles64Folder I am getting following error
: error LGHT0204 : ICE80: This 32BitComponent jODBCRegKeys uses
64BitDirectory ProgramFiles64Folder
I have double checked my all binary files are 64bit
How can I get rid of this error ?
Manoj
-Original Message-
From:
I saw a user with a very similar sounding issue because he'd used the
"Windows Installer Clean Up" tool to remove a build of our software he
believed was a "bad install" (thanks InstallShield et al for
mis-educating users for years) & then re-installed using the same
installer. He knew nothing of C
Use a Type 51 Custom Action.
[author your plug-in components & directory structure here]
Substitute GITSEARCHPROPERTY for whatever you have named the Property
you populate with the RegistrySearch. That way GITLOCATION will be
dynamically set d
It's kinda' tricky. Properties can be treated like Directories. So name a
Directory/@Id the same as your Property/@Id for the search. This might be
useful:
http://blogs.msdn.com/b/robmen/archive/2006/10/17/deciphering-the-msi-directory-table-part-7-directories-are-properties.aspx
On Fri, Jan 21, 2
Maybe the File Versioning Rules documentation explains why the file is not
being installed:
http://msdn.microsoft.com/en-us/library/aa368599(VS.85).aspx ?
On Fri, Jan 21, 2011 at 7:36 AM, Florian Schricker wrote:
> Hello wix-users,
>
>
> I have the following problem:
> Using a separate, second fe
Hi
I am trying to build a installer for 64bit installer.
I want to set default directory *c:\Program Files\* instead of *c:\Program
Files (x86)\*
*
*
I don't have any 32 bit binary in my components list * *
can you please guide me how can I do this?
---
Hmm, you may have confused the Windows Installer. Mucking around with their
private store isn't usually a good idea.
On Fri, Jan 21, 2011 at 6:59 AM, Thorsten Tarrach wrote:
> Hello,
>
>
>
> I played around with Major Updates and somehow I got into a situation now
> where none of the files is re
Actually, for Package/@Platform, it is better to use the -arch switch on the
command-line. That will flip your entire package to x64 as needed.
On Fri, Jan 21, 2011 at 7:37 AM, Rob Hamflett wrote:
> Use Directory@Id="ProgramFiles64Folder" and Package@Platform="x64".
>
> Other pre-defined folder
Use Directory@Id="ProgramFiles64Folder" and Package@Platform="x64".
Other pre-defined folders are listed here:
http://msdn.microsoft.com/en-us/library/aa370905%28VS.85%29.aspx#system_folder_properties
Rob
On 21/01/2011 15:32, Manoj Jangid wrote:
> Hi
>
> I am trying to build a installer for 64bi
Hello wix-users,
I have the following problem:
Using a separate, second feature I allow the user to install a file
containing "factory defaults" only if he needs to. So by default this
feature is not a activated for install.
If installed once it is important that it is not removed by an
uninstal
Hi
I am trying to build a installer for 64bit installer.
I want to set default directory *c:\Program Files\* instead of *c:\Program
Files (x86)\*
*
*
I don't have any 32 bit binary in my components list.
* *
can you please guide me how can I do this?
Thanks
Manoj
---
Is there another property?
On Jan 21, 2011, at 8:40, Rob Mensching wrote:
> I agree.
>
> On Fri, Jan 21, 2011 at 5:43 AM, Michael Urman wrote:
>
>> It would be nice if the documentation stated that outright. I
>> understand the normal UAC case made Privileged hard to set as
>> documented, but
Hello,
I wrote an installer that installs my application in Program
Files\[Company Name]\[Product Name].This is a plugin for Git. I need
to install my plugin *and* add the correct hook to the Git directory.
Where Git is installed, is found out by using a registrysearch.
I'm using the registrysear
Hello,
I played around with Major Updates and somehow I got into a situation now
where none of the files is removed by uninstallation. It is not an error
with the package, as the latest version works quite fine on a different
machine.
It must be something in the registry of that machine. But I
Thank you Maksim the property is now being set correctly. Sadly my other
features and the checkbax are ignoring the value anyway :( Maybe one for next
week .
-Original Message-
From: Simon Topley [mailto:simon.top...@mwhsoft.com]
Sent: 21 January 2011 11:57
To: General discussion for Win
I expect it also depends how you schedule your Major Upgrade. If you remove
one MSI completely then install the second (early RemoveExistingProducts)
and that gets canceled, then I expect the file would be rolledback because
the second install is essentially a clean install.
If you schedule Remove
Oh, if you want to access it from a different MSI then you need to use
AppSearch (the *Search elements in WiX).
On Fri, Jan 21, 2011 at 4:32 AM, Umeshj wrote:
>
> How do we access it?
>
> Specifically, I would like to show the user in the UI - during upgrade -
> that the previous version is inst
Yeah, sorry, there are some anachronisms in the binder variables that are
not stored in my memory correctly because I spend too much time thinking
about how they need to be fixed.
On Fri, Jan 21, 2011 at 12:20 AM, Rune Moberg wrote:
> On Thu, Jan 20, 2011 at 2:01 PM, Rob Mensching
> wrote:
> >
I agree.
On Fri, Jan 21, 2011 at 5:43 AM, Michael Urman wrote:
> It would be nice if the documentation stated that outright. I
> understand the normal UAC case made Privileged hard to set as
> documented, but as written this behavior smells more like a Windows
> Installer bug.
>
> On Thu, Jan 20
Just make sure you install a component to that directory - it doesn't
even need to contain any files. Then Windows Installer will remember
it for you, loading it back into the DirProperty.
On Fri, Jan 21, 2011 at 06:32, Umeshj wrote:
>
> How do we access it?
>
> Specifically, I would like to show
It would be nice if the documentation stated that outright. I
understand the normal UAC case made Privileged hard to set as
documented, but as written this behavior smells more like a Windows
Installer bug.
On Thu, Jan 20, 2011 at 22:43, Rob Mensching wrote:
> Windows Installer always sets Privil
How do we access it?
Specifically, I would like to show the user in the UI - during upgrade -
that the previous version is installed at "" location and upgrade will
take place by placing newer version in the same directory.
Thanks
Umesh
Rob Mensching-7 wrote:
>
> Hmm, I don't remember
a! I see, the "sequence" can be both, ui or execute, sorry I just assumed
is was a number! I'll try this.. Thanks for your patience Maksim
-Original Message-
From: Simon Topley [mailto:simon.top...@mwhsoft.com]
Sent: 21 January 2011 11:47
To: General discussion for Windows Installer
You have to run SetProperty custom action AFTER the dialog in which user
selects all features he wants, not after CostFinalize. Now you set the property
when you don't know what will be installed.
Maksim.
-Original Message-
From: Simon Topley [mailto:simon.top...@mwhsoft.com]
Sent: Fri
costFinalize maybe too early since the user has'n yet selected which features
they want, but it is the only one I can us with getting " light.exe : error
LGHT0001 : Found an ActionRow with a non-existent Before action."
-Original Message-
From: Simon Topley [mailto:simon.top...@mwhsoft.
I don't see why it would be a problem to have it scheduled in both as it
amounts to the same thing, the property is set before the last dialog is shown
and before the files are installed.
Maybe I should clarify my question:
I have an installer with 3 features, a b and c, each contain a componen
Read WiX documentation.
'Sequence' attribute controls which sequences the Property assignment is
sequenced in. For 'execute', the assignment is scheduled in the
InstallExecuteSequence. For 'ui', the assignment is scheduled in the
InstallUISequence. For 'both', the assignment is scheduled in both
Sorry ignore that, I see that they have the same sequence in both tables. So
this should mean that the property is being set before the dialog is shown.
-Original Message-
From: maksim.vazhe...@emc.com [mailto:maksim.vazhe...@emc.com]
Sent: 21 January 2011 10:46
To: wix-users@lists.sourc
I see, so when I ask for CostFinalize I get it in the UI AND execute sequence.
Is there any way to tell it to only use one of the other? Would this have a
knock on effect on using the same property to enable/disable other features?
Simon
-Original Message-
From: maksim.vazhe...@emc.com
The entry in the log
MSI (c) (7C:10) [08:01:24:535]: Skipping action: SetCONFIGREQUIRED (condition
is false)
is written when the custom action runs during InstallUISequence, and
MSI (s) (5C:2C) [08:01:43:082]: PROPERTY CHANGE: Modifying CONFIGREQUIRED
property.
is written during InstallExecuteSe
As a fun experiment I changed another feature to be installed if the value is
1, so I have 2 features now, one will install if CONFIGREQUIRED is "1", the
other won't install if it is "1".. neither installed, so obviously something is
wrong with either the whole idea of have one feature hinged of
The Windows Shell/Control Panel runs MSIs that are in ARP in "Basic U/I"
mode. Windows Installer skips InstallUISequence when UI is "Basic". The only
workaround is to use ARPSYSTEMCOMPONENT and create your own ARP registry
entries.
From: Arun Kumar [mailto:arun_jku...@persistent.co.in]
Sent: W
When you say "never removed even on rollback", do you mean never removed
on uninstall either?
If so, you can set your component's guid to an empty string. Meaning
Windows Installer will not "manage" the component at all - so it won't
be able to remove it.
But Windows Installer also won't be able
I'm still stuck with this one. There is something very odd going on in the log
I guess it is possible that the log is inaccurate as I get the same result in
both the logs but different behaviour from the checkbox on the last dialog.
NOT Installed AND
(CONFIGREQUIRED=1)
Unless you authored the "error message during installation that another
version has already been installed and this needs to be first uninstalled
before proceeding with the install" then might be attempting a minor update
(my term for what would be a minor upgrade, except the fourth part of the
ver
These are the relevant parts of the attempted removal of the existing
product during RemoveExistingProducts (as part of an attempted major
upgrade):
*** Product: {8B696937-064A-4A31-8249-7BC62885F793}
*** Action:
*** CommandLine: ** MSI (s) (C8:
On Thu, Jan 20, 2011 at 2:01 PM, Rob Mensching wrote:
> If you don't want to generate another file (this is what WiX does), then my
> new favorite trick is to do:
>
> Product/@Version="!(wix.FileVersion.SomeFileIdInYourMsi)"
Had I read your e-mail yesterday, I would have slept much better last ni
51 matches
Mail list logo
