Thanks.
Yes, I'm using WixUI. v2. But as if properties work.
1
2
3
4
5
6
7
8
9
10
11
12
13
141
15
16
17
18
19
201
21
22
line 3~line 11 do work except line 7. i.e. i can not move back to myDlg from
VerifyReadyDlg through the Back button on the VerifyReadyDlg. (but i can move
back to We
Hi Alex,
Thank you very much for your information. Actually I don't worry about whether
minor upgrade or major upgrade. When user install the same installation
directory as pervious version, I will replace/upgrade that version with the
latest install.
Example:
I got the following version i
LOL Just writing registry keys, of course, is not the only thing that happens
inside .NET custom actions. Sometimes we have to read a registry key already
written and perform a certain action, or write a new key whose value is not
that easily derived to be handled by the Registry table.
Bob Arns
Hi,
My scenario is an automatic distributed setup/deployment. There are many msi's
scheduled to be installed to different servers. All web services are installed
to default web site. Each web service has its own application pool. I need to
control when to start a web service after it is instal
I am a member of a small community of video editors, and this hobby
requires a large amount of freely available software. In order to make
it easier for users to find and install all of the software that they
need, we package it all into a single, easy to use installer.
This installer is curren
Dear friends,
I hope you are fine and doing well. Thank you for the helps you've ever done
I have a problem with custom actions, which couldnt find its solution. One
of the files which is going to be installed on the target machine can not
work if there is a space in the path, so I need to chec
I might think a generic implementation to support this scenario of allowing
users to define public property values on the command line and/or in a single
xml file would involve a customAction sequenced to process right up front
during install/unstall and simply read the one per line property=val
By "moved into place" I'm referring to the default web.config & app.config
having been copied by the msi to the INSTALLDIR path where they need to reside.
Once in place I was hoping that XmlConfig allows me to update entries
configured with default settings in these files with a host specific v
Robert O'Brien wrote:
does current wix drop provide support for a public property such as
"msiexec /i myservicedeliverable.msi propertySettings=
environmentSpecificPropertySettings.xml ..." where
environmentSpecificPropertySettings.xml consists of a single public
property=value pairs on each
Arthur Curvello wrote:
I've created a localizable string variable(SQLSrvName), linked it to a
property(SQLServerName) of an edit of a dialog.
the variables receive the values, BUT, the Server="!(loc.SQLSrvName)"
do not repass the value to the connection string.
log line:
MSI (s) (B0!40) [15:18
[EMAIL PROTECTED] wrote:
My permanent component didn't work just right the first time, so I
need to try it again. If there's really no way to uninstall a
permanent component for debugging, then is there a way to force a
permanent component to be re-installed?
You can upgrade it but not u
Dwyer, Shawn wrote:
What are the factors in how long it takes Light to run? Is it
dependent on the number of Components?
Yes, to an extent. Mostly it's the size of all the files because they're
generally compressed into cabinets. You can use the -v0 switch to have
Light log status messag
Robert O'Brien wrote:
is XmlConfig intended for service deliverable cases where you want to
modify web.config & app.config settings after putting file into place?
Yes, among other use cases.
On a similar front should one expect the Action="create" behavior to
support update of a default n
Donal McWeeney wrote:
> Thanks for the answer. After understanding the upgrade table a bit more
> I realised that the previously authored msis were installed per-user and
> we need to do it per-machine, and the FindRelatedProducts does not
> search across context.
>
It doesn't do that because i
Xu nanxuan wrote:
> Thanks. In fact, the "Property" does work, Things are like the following:
> if i want to the following sequence: myDlg->VerifyReadyDlg, the
> following things work:
>
>
>
>
>
>
>
> but i don't know why i can't make the back button of VerifyReadyDlg
> run through the same met
Ted Berg wrote:
> My concern is that the GUID for any given component in the various
> packages is the same. The files associated with the component are
> installed into a different directory for each package.
>
That violates component rules, which is a problem mostly when you want
to do mi
Sanin wrote:
> 2. Explicitly pass appropriate flag when using registry classes from .NET so
> that automatic redirection does not happen.
>
Why would you go through the hassle of writing a C++ custom action that
loads a .NET assembly to write to the registry when MSI already supports
64-bit r
Wilson, Phil wrote:
> When people require files removed I've marked them as transitive components
> with a condition that evaluates false. As you know, removing components
> during a minor update is not supported.
>
I've been able to successfully avoid the issue. Usually, being able
to unins
The WiX toolset works somewhat like a C++ toolset. Candle is a 'compiler'
which parses your source code and turns it into 'object code' - in this
case, effectively writing the rows that will be written to the MSI, with
placeholders where necessary if a reference is not resolved within this
fragment
Thanks for the answer.
The problem is that I need contradictory rules on install vs. repair and
different rules for different files.
As MSI only seems to offer *global* versioning rules (through REINSTALLMODE)
I can't seem to get the needed behaviour :-(
-Mark
-Ursprüngliche Nachricht-
20 matches
Mail list logo
