I've seen people use that syntax as well, but have you tried something like
[INSTALLDIR]SystemSettings.xml, assuming the file is being laid down in
INSTALLDIR?
On Wed, Aug 13, 2008 at 5:46 PM, <[EMAIL PROTECTED]> wrote:
>
>
>
> Am I correct to assume that using [#fileid] syntax to refer to a file
I've got one working version and it turned out to be very quick and
easy. I tested it on one pristine XP SP2 installed in Virtual PC and it
works like a charm. Quite a relief after waiting one hour for SP1
install to tell me that I need to close WiX.chm HTML Help file.
The procedure is the followi
That's correct. This is alluded to in the documentation for ICE warning 69 at
http://msdn.microsoft.com/en-us/library/aa369019(VS.85).aspx:
"If the component referenced with the [$componentkey] property is already
installed and is not being changed during the current installation (for
example,
The original install is InstallScript based (and was called out as such in the
original email).
The search:
does find the file rbfta.exe, but the feature never gets installed.
Am I correct to assume that using [#fileid] syntax to refer to a file
does not work if that files' component is marked with
Permanent="yes" and/or NeverOverwrite="yes"?
I.e. it will only be correctly evaluated if the installer actually
"processes", e.g. installs, the file.
Example:
...
What about whether the very old InstallShield is an MSI-based install or not?
If it's MSI based you're doing an upgrade in an unsupported manner, one MSI
install with some set of product and component guids directly on top of another.
If you do the install taking a MSI log it will say something
Unfortunately that registration is still incomplete for a .NET assembly. You
need assembly name attributes plus the InprocServer32 Dll isn't your assembly,
it's msicoree.dll.
If you run regasm on your assembly with the /regfile option it will generate a
.reg file that will show you what regist
okay, thanks does this require using wix 3.0? This product is currently being
built with 2.0.
Karen
dB. wrote:
>
> The simplest thing is to use QuietExec (a wix custom action, see wix
> manual) for executing jar.exe. You could fetch the environment variable
> for JAVA_HOME and execute JAVA_HOM
Also, You could start the path like this... //mycomponent/section/
Jim Evans wrote:
>
> You're right, I did. It's a typo on my part. In my actual code, the name
> attributes match. Here is the corrected set of code samples:
>
> Target XML file:
>
>
>
>
>
>
>
>
If it's still not working... try this instead:
ElementPath="/configuration/myComponent/section/[EMAIL PROTECTED]'foo'[\]]"
VerifyPath="/configuration/myComponent/section/[EMAIL PROTECTED]'foo'[\]]"
Then it will update "foo" w/ the property you pass in for the Value.
Jim Evans
Hi Johan,
Johan Appelgren wrote:
>
>
> That is determined by the ALLUSERS property. If it is not set you get
> a per-user installation, so I'm guessing that is what you have.
>
>
OMG, your guess was right. I normally place the ALLUSERS property in every
WiX project I create but this time I
That's misleading, if you set it up correctly, you can use action="create"
to actually update an existing entry. You just have to be careful of escape
chars.
This would work for an '' ---> ' structure
elementpath="//appSettings/[EMAIL PROTECTED]'somekey'[\]]"
Just toss in the value you want in
In Wix 3.0 we have both the XmlConfig and XmlFile elements.
I'm not totally clear about what is the difference between XmlConfig
and XmlFile. Can somebody explain? Why do we have two different elements
that seemingly can do the same (or can they)?
Accordingly to Bob Arnson [see
http://n2.nab
Hi,
I checked verbose debug installation log and corrected the error, but
the initial issue is still existing, i.e,
DLFetcher Component is not registered[object error]
Can you please check the COM registry that I have made and let me know
what to do further?
COM registry in my WIX fi
Hi,
I checked verbose debug installation log and corrected the error, but the
initial issue is still existing, i.e,
DLFetcher Component is not registered[object error]
Can you please check the COM registry that I have made and let me know what to
do further?
COM registry in my WIX fi
I want to create an install-experience which should support the
following:
* If the install-user selects a particular feature for install, that
feature should install a new virtual directory in the default IIS web
site.
* If IIS is not installed the install should not fail if the user
haven't
Hi,
I checked verbose debug installation log and corrected the error, but
the initial issue is still existing, i.e,
DLFetcher Component is not registered[object error]
Can you please check the COM registry that I have made and let me know
what to do further?
COM registry in my WIX
On Wed, Aug 13, 2008 at 1:47 PM, Stefan Kuhr <[EMAIL PROTECTED]> wrote:
>
> Hi Johan,
>
>
>
> Johan Appelgren wrote:
>>
>> Are you doing a per-user or a per-machine install?
>>
>>
>
> Oops, please excuse my ignorance, but how do I know that? The command line
> is the same as I would install as an i
Hi Johan,
Johan Appelgren wrote:
>
> Are you doing a per-user or a per-machine install?
>
>
Oops, please excuse my ignorance, but how do I know that? The command line
is the same as I would install as an interactive user, something like:
msiexec.exe /i path-to-my.msi /qn /l*v path-to-logf
The simplest thing is to use QuietExec (a wix custom action, see wix
manual) for executing jar.exe. You could fetch the environment variable
for JAVA_HOME and execute JAVA_HOME\bin\jar.exe with whatever parameters
you need. Schedule the custom actions after InstallFiles in deferred
mode.
If someon
Hi Pierson,
Pierson Lee wrote:
>
> Two questions:
> 1. If you run through interactive does it appear in ARP?
> 2. Do you have the GUIDs setup for Product Code, Upgrade code, Components,
> etc?
>
The answer to both questions is yes.
--
Stefan
--
View this message in context:
http://n2.nab
On Wed, Aug 13, 2008 at 9:08 AM, Stefan Kuhr <[EMAIL PROTECTED]> wrote:
>
> Hello everyone,
>
> I have an MSI built with WiX. If I install this using msiexec from the
> SYSTEM account, the product gets installed (files and registry keys are
> there) but it is not visible in ARP. Also if I run this
Really? I was led to believe otherwise, I'll let you know when I get a
working version.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tony Juricic
Sent: 13 August 2008 06:24
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-user
I had the same problem. I had to recreate the wix project files and the
solution files to "fix" the problem. (basically I created a new project and
reimported my wxs files).
If you figure out what the exact changes are, let me know, but I was on a time
crunch and this fixed my problem.
-Ori
Two questions:
1. If you run through interactive does it appear in ARP?
2. Do you have the GUIDs setup for Product Code, Upgrade code, Components, etc?
Thanks
Pierson
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Kuhr
Sent: Wednesday, August 13,
Hello everyone,
I have an MSI built with WiX. If I install this using msiexec from the
SYSTEM account, the product gets installed (files and registry keys are
there) but it is not visible in ARP. Also if I run this MSI then again from
an interactive user, I do not get the option to repair or remo
26 matches
Mail list logo
