Hi Leila
I have tested this and it works.
Some disadvantage is that the console windows is visible for some
tims (cca 0.5 s).
I hope it will help you...
Stefan
Leila Lali (Excell Data Corporation) wrote:
> Yes it works. I’ve used Custom Action type 34 like this:
>
>
>
> ExeCommand='"[Pr
Title: RE: [WiX-users] Installing machine-specific license files
Actually, I was thinking I could use the same product code, upgrade code, and component ids for each customized license file installer. I don't think this will be a problem. Am I missing something?
-Original Message-
Young, Jason (GE Indust, GE Fanuc) wrote:
> Anyone have an example of checking if a certain feature is selected?
>
See "Examples of Conditional Statement Syntax" in the MSI SDK for
examples of the & prefix to detect feature action state.
> Also, does anyone have a full example of a dialog that
Calin Iaru wrote:
> I see that MigrateFeatureStates discovers that the features are
> installed. Next, InstallValidate says that the feature is absent when
> the versions do not match (ie install with one MSI and uninstall with
> the other). RemoveExistingProducts is skipped in both cases (remov
Don Pratt wrote:
> (directed to the list at large...)
> If you put the registry value in it's own component and use the same
> component GUID for al of your installs, shouldn't MSI's reference
> counting keep the key around until all of the apps that need it are
> uninstalled?
>
Sure, that ma
Arnette, Bill wrote:
> So my plan is to create a WiX project that the licensing system builds
> whenever it gets a license request. The licensing system will generate
> the license files and then build the WiX project.
> I'll create a WixLib with the components for the license files. After
> the
Wilson, Phil wrote:
> If Wix actually
> has a built-in custom action that does a shell open on a file then it
> would work for probably all these situations, whether it's a URL, a text
> file, an RTF file, chm, mp3, wav, csv, and so on, and it would use the
> app that the user wanted, not that one
Without seeing the code, I’d have to
guess. But I think that private properties can’t be set or changed, only
public. Public properties are always in all caps. Maybe the ProgramFilesFolder
is taking precedent because it’s initially defined in TARGETDIR? As a
test, compile and try the instal
Ok so that worked, if I do that syntax
with the “” I see in the log file where the targetdir get’s
set… however it still installs to the program files directory.
I then tried setting the
ProgramFilesFolder to c:\temp.. again the logfile shows it being set but it
still resolves the real
That'll work, sure. It's just that my default way of thinking is "shell
open" to avoid the issues that people have trying to open doc, htm, txt,
you-name-it file extensions and going off into discussions about how to
find IE, Winword, Wordpad or whatever. Shell open just circumvents most
of these
Try this:
TARGETDIR=”c:\temp”
I can’t find any documentation to
corroborate it, but all the auto-deployment scripts I have set public
properties with quotes, even when there are no spaces or odd characters in it.
I must have done that for some reason when I wrote them months and mon
I am trying to the TARGETDIR through the cmd line when
running my MSI but it get’s completely ignored…. Some customers
might need to overwrite the default value so they have requested this msiexec
function to work.
The syntax I am using is msiexec /I foo.msi TARGETDIR=c:\temp
Is the
I'm not a WiX or install expert by any means, but this worked for me:
(NOT Installed) AND (UILevel=5)
John
Wintellect - Know How
http://www.wintellect.com
877-968-5528
> From: "Wilson, Phil" <[EMAIL PROTECTED]>
> Date: Thu, 28 Sep 2006 12:3
Anyone have an example of checking if a certain feature is selected?
Also, does anyone have a full example of a dialog that prompts for SQL
Server credentials? I'm hoping that I don't have to build one.
Thanks,
Jason
-
Take
I see that MigrateFeatureStates discovers that the features are
installed. Next, InstallValidate says that the feature is absent when
the versions do not match (ie install with one MSI and uninstall with
the other). RemoveExistingProducts is skipped in both cases (remove from
different version
Take a look at the Upgrade topic in MSI SDK. The Upgrade element in the
WiX.chm should link to it. That plus RemoveExistingProducts should get you
what you're looking for.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Calin Iaru
Sent: Thursday, Sept
The general approach to this is to do whatever it takes to run a
ShellExcute "open" on the file. For doc, chm, html or whatever
extension this will invoke the handler for it, just like double-click.
Details depend on your choice of language for the custom action, but C++
has ShellExecute() that ta
Short note:
InstallValidate does not discover any of the Features as being installed.
Calin Iaru wrote:
> Hi List,
>
>I have 2 MSI packages which are compiled with different versions and
> different product code GUIDs. I want on the newer one to offer the
> possibility to remove the ins
Hi List,
I have 2 MSI packages which are compiled with different versions and
different product code GUIDs. I want on the newer one to offer the
possibility to remove the installation. How can I do this? I have tried
several times to trigger a Remove event on the new version, but I still
ha
I've been banging my head all day trying to figure out how to launch a
CHM at the end of my install. I'm trying to use a custom action, and I
got it to work for an EXE, but not the CHM. I would like to load it
based on a FileKey if possible. I don't really understand what the
documentation means
Our licensing system is similar to Windows Product Activation in that a
hash is created for the machine the software is licensed on, sent to us,
and we return a self-extracting executable that installs a bunch of
license files that are generated for that specific machine. What this
means is that
John G wrote:
> I ran the test on a "simple" msi (below) and it did get past the exception.
> Still, it ended with the following error -
>
> *
> E:\TestArea\WiXTest>e:\WdkTools\smoke Test.msi e:\WdkTools\darice.cub
> Microsoft (R) Windows Installer Xml Validator
Leila Lali (Excell Data Corporation) wrote:
Yes it
works. I’ve used Custom
Action type 34 like this:
You mean to set the 'Compatibility Mode' to 'Windows XP SP2', as if
you'd done it on the Compatibility tab of the EXE file's property sheet
in Explorer?
Not that I'm aware of.
I believe these settings are stored somewhere in the registry, but it's
not a documented location.
--
Mike Dimmick
---
Hi all,
I have small question:
Is it possible to set the XP compatibility mode for some installed
exe using Windows Installer (4.0)?
Our software needs to be rewriten a bit for Vista but till this time
I want to test the installation also on Vista.
Thanks for any reply
stefan
--
Stefan
Feature Requests item #1566967, was
opened at 2006-09-28 13:27
Message generated for
change (Tracker Item Submitted) made by Item Submitter You can respond by
visiting: https://sourceforge.net/tracker/?func=detail&atid=642717&aid=1566967&group_id=105970
From: Mike Dimmick
[mailt
It looks like, at the moment, you will need to create your
own custom action to do this.
In WiX 2.0, the element is only for defining
a group to be referenced with elements. These are for adding a
user (possibly created by the installation) to an existing group. The only
change for WiX 3
Is this possible, if
so, how? I'm not talking about actual users, but
users-groups.
I've been thinking
that the -element was made for this, but now when I've looked
a little closer, I've changed my mind. I'm currently using version
2.0.3309.0 of WiX, is there more documentation rega
28 matches
Mail list logo
