[WiX-users] Always install a specific feature/component ...
And once more I need to seek your help.
I have an application, which has a license file, let's call it
license.dat. Per default the contents of license.dat puts the
application in a kind of demo mode and encourages the user to register
over the Internet. I authored it to be a component with a specific GUID.
The application is another component with a different GUID, and both are
installed as a single feature. Works nicely, easy job.
Some day, to get the full features, the user registers his product over
the Internet. Technically the license.dat file gets overwritten with a
new one, containing license info. The license info in the file unlocks
the application's full features for a specific time. Once the license
expires, the application resets itself to demo mode (without touching
the license.dat file, it knows from the contents of the file that the
license has expired). Works too.
And now things get weird. The application's marketing concept is
modular, which means that the user may after some time purchase another
module of this product and install it. The new module does also come
with the same license.dat file that contains the demo license. The same
component and GUID like above is used to author the same component like
above, since it is the same file as above, and despite that there isn't
a way to tell which product modules someone purchases in which order, so
every module can potentioally be the first one (and probably even the
only one) a user installs, and thus every modue must contain the demo
license.dat file.
It is the intention of the vendor that in case of installation of a
second (third, fourth .-..) module the demo license.dat file overwrites
the old (registered or unregistered, don'tcare) one, so the user does
need to register again (whch will reset the usage time, so he can
utilize the product for a full time period again). Unfortunately smart
Windows Installer thinks, he already has installed the component, and
skips it, so the license.dat file is not reset to the demo license, the
user has no reason to re-register, and the application reverts to demo
mode as soon as the old license expires. At this point the user would
either call suppport and complain that his license expired prematurely,
or be a smart one and use the license of the second purchase to
re-activate the product, which is OK, but inconvenient after such a long
time after installation.
No problem, you'd say, just author the component containing file using a
differend GUID, and the file will be overwritten. Great, but what
happens during an uninstall? If the user uninstalls either component,
the file will get deleted, since it's reference count is 1. The
application will stop working, because it does have neither a demo nor a
registered license.dat file, though all but one modules are still installed.
The obvious solution wold be to author the component using the same
GUID, so the reference counter gets 2, but have it overwrite ("refresh")
the file. When uninstalling, the reference counter would decrease, but
the file would be left unchanged, which is exactly what I want.
Unfortunately I found no option setting for either component or file to
get this behavior.
All together: how can I author a shared component which "refreshes"
itself when installed a second, third, ... time, but shows normal
uninstall behaviour (decrease the reference counter, and get deleted
when the internal reference counter reaches 0)?
Another approach would be: the application has several other files which
show correct installation/deinstallation behaviour when installed by
multiple products (increase reference counter with every installation,
decrease it with every uninstallation, and delete it when the counter
reaches 0). If I could find a way to tie the deletion of the license.dat
file to the deletion of one of those files, this would save me as well.
And probably I missed something entirely, and tehre is another way to
get what I need using a different approach?
Any hints/ideas/leads to documentations welcome,
Armin.
P.S. Just to mention it, the behaviour of the copy protection/licensing
software, which is a 3rd party product, can, unfortunately, not be
influenced. Messing with the license.dat file is the only way..
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WiX Editor: Preset the "Use custom commandline for light.exe" setting
Hi all, for my installers I du almost always need the -cultures switch. Unfortunately the WiX Editor does not remeber this if closed. Does anyone know wether it is possible to change the default command line options for light.exe? Thanks Armin. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditional installation depending on file existence
Hi Alexander,
> All custom directories, like SHELLPATH are represented as properties and they
> will get their values after CostFinalize (suggested sequence number in
> InstallExecuteSequence - 1000). Your an AppSearch (suggested sequence 400) and at the time of AppSearch property
> SHELLPATH does not have any value yet. That is your main problem. How to
> fix it? Either use ComponentSearch/FileSearch to find where component/file
> is installed or store [SHELLPATH] in the registry during install and use this
> registry value in your AppSearch.
>
Thanks very much for your explanation, I haven't tried this yet, but I
guess this explains the problems I have (except the question why the
condition didn't show up in the msi table at all). Thanks again for the
suggestion how to solve it, I'll give it a try today.
> Also, I am not sure I understand your objectives here. You don't want your
> users to be able to uninstall your feature once they installed it?
>
I guess you mean the missing OR INSTALLED usually in the filter. I'll
include that in my final installer, so far I could not install the
component, so I didn't notice this glitch yet.
Besides ... you seem to be one of the guys knowing more ... some pieces
of docs I found write filters like !(ISSHELLINSTALLED or INSTALLED),
others do additionally put a CDATA[] around it. I could not find a word
of documentation anywhere what the CDATA statement is good for, it can
obviously be omitted, so what is it good for?
Greetings from Munich, and many thanks again,
Armin.
> Alex
>
>
>
> -Original Message-
> From: mirram...@googlemail.com [mailto:mirram...@googlemail.com]
> Sent: Monday, October 26, 2009 4:18 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] Conditional installation depending on file existence
>
> Hi all,
>
> after hours and hours of stabbing in the dark I ask you for your help. I
> have a msi file which contains the following elements:
>
> - <#>
> - <#>
>
>
>
>
> ...
>
> - <#>
> - <#>
> - <#>
> - <#>
> - <#> DiskId="*1*" Guid="*F99A956C-9671-4F15-BE6C-BE9841852AEF*">
>Name="*SoGehtsMenu.exe*" Source="*D:\So Gehts 10-Film
> Test\Flat\Shell\SoGehtsMenu.exe*" />
>Name="*SoGehtsTreeUpdate.exe*" Source="*D:\So Gehts 10-Film
> Test\Flat\Shell\SoGehtsTreeUpdate.exe*" />
>Name="*SoGehtsShell.exe*" Source="*D:\So Gehts 10-Film
> Test\Flat\Shell\SoGehtsShell.exe*" KeyPath="*yes*" />
>Name="*SoGehtsShell.mmf*" Source="*D:\So Gehts 10-Film
> Test\Flat\Shell\SoGehtsShell.mmf*" />
>Name="*SoGehtsShell.lic*" Source="*D:\So Gehts 10-Film
> Test\Flat\Shell\SoGehtsShell.lic*" />
>Source="*D:\So Gehts 10-Film Test\Flat\Shell\SoGehts.css*" />
>Source="*D:\So Gehts 10-Film Test\Flat\Shell\Help.html*" />
>Source="*D:\So Gehts 10-Film Test\Flat\Shell\Intro.html*" />
>Name="*Impressum.html*" Source="*D:\So Gehts 10-Film
> Test\Flat\Shell\Impressum.html*" />
>Source="*D:\So Gehts 10-Film Test\Flat\Shell\Logo.jpg*" />
>Source="*D:\So Gehts 10-Film Test\Flat\Shell\Intro.png*" />
>Key="*Software\SoGehts GmbH\Shell*" Name="*ShellPath*" Type="*string*"
> Value="*[SHELLPATH]*" />
>
>
>
>
>
> ...
>
>
> - <#>
> - <#>
> - <#> Guid="*F99A956C-9671-4F15-BE6C-BE9841852AE7*">
>WorkingDirectory="*SHELLPATH*" Arguments="*/Shell:"[SHELLPATH]"
> /Films:"[FILMSPATH]" /R*" Target="*[SHELLPATH]\SoGehtsMenu.exe*" />
>Directory="*ApplicationProgramsFolder*" />
>Value="*[ApplicationProgramsFolder]*" KeyPath="*yes*" />
>Directory="*ApplicationProgramsFolder*" WorkingDirectory="*SHELLPATH*"
> Arguments="*/x [ProductCode]*" Target="*[System64Folder]msiexec.exe*" />
>
>
>
>
> ...
>
> - <#>
>
>
> ISSHELLINSTALLED
>
>
> The objective is, I think, clear: the "SoGehtsShell" Feature must only
> be available when it hasn't been already installed. I inted to detect
> the previous installation by checking wether the file SoGehtsShell.exe
> exists. This sets the ISSHELLINSTALLED property to a non-empty value,
> which should then trigger the Condition in the SoGhetsShell feature. I
> cannot figure out why this does not seem to work at all. No matter
> wether the file is there or not, the component is always installed.
> Reading the logs I found no trace of any ISSHELLINSTALLED condition.
> Looking into the .msi with ORCA I found the "condition" row of the
> "Component" table empty.
>
> I feel not guilty. The xml (in my opinion) contains everything mentioned
> in the WiX Tutorials ("conditional installs"), but it never
[WiX-users] WixUI_FeatureTree: disable (lock) target directory selection
Hi all, is it possible to disable the target directory selection GUI elements, depending on a condition? The whole story: a product is delivred in modules (each is one msi) which a user can purchase and install in any order. It is essential that he always selects the same target directory. The directory is memorized via registry, so if he just accespts the defaults everything is fine. But he still can choose to select a differet diectory, so after the first install I'd like to show the target directory selection (so he sees where the data will go), but not let him change the path any more. Can this be done? Thanks, Armin. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Sequencing custom actions
Hi WiX users, I am seeking advice how I can accomplish the following: I found out how to sequence custom actions "after InstallFinalize". For my installation requirements I need a finer degree of control when custom actions are run, particularily I am seeking for a way to execute a custom action "after successful installation of component/feature xyz" and "after deinstallation of component/feature xyz" (regardless wether successful or not). Can this be done? The whole story: I have a msi that contains 2 components/features, lets name them MainComponent and OptionalComponent. MainComponent includes an .exe which needs to run if OptionalComponent is installed. Likewise, if OptionalComponent is deinstalled, the .exe needs to run again. If both MainComponent and OptionalComponent are selected for uninstall, OptionalComponent needs to be uninstalled, then the .exe must run, and then MainComponent needs to be uninstalled. Doesn't look to difficult, but reading the docs about sequencing actions I found nothing hepful. Can anyone help me? (A pointer to a piece of documentation will do nicely ...) Thanks, Armin. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Fixed: Quote-in-quotes problem in ExeCommand, a WiX bug, or am I missing something?
Hi all, I found the source of the problem, and it has nothing to do with WiX at all. The xml snippet I posted was copied from Internet Explorer (aka "XML Editor"). I did not consider, that relying on what this tool displays might be misleading, since it does not actually display the contents of the xml byte by byte, but display an already interpreted representation of the xml. Looking into the xml file directly using an hex editor revealed, that the actual xml contents was: ExeCommand="/Path:"[MyDataPath]"" If you look at this xml through XML editor it looks exactly like the sample code I intended to use .-) I corrected it, and the custom action worked like a charm. Many thanks to those who looked into my post, Armin. 2009/9/18 David Watson > hi, > Did you try > > ExeCommand='/Path:"[MyDataPath]"' Return="asyncWait">NOT > Installed > > I think xml lets you get away with ' or " for attributes. > > Dave > > -Original Message- > From: Armin Linder [mailto:mirram...@googlemail.com] > Sent: 18 September 2009 11:26 > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Quote-in-quotes problem in ExeCommand, a WiX bug,or > am I missing something? > > Hi WiX experts, > > before I wave the "bug" flag, being relatively new to WiX, I am asking > you to review this problem, and probably give me advice how to > circumvent the following weirdness: > > my xml is: > > ExeCommand="/Path:"[MyDataPath]"" Return="asyncWait">NOT > Installed >NOT > Installed > > Since [MyDataPath] does most likely point to a "documents and > settings\" > subfolder, I enclosed the command line parameter in double quotes by > adding ". > > The installation runs through, but when my program "update.exe" gets > executed, it complains about a non-existing path passed via tha /Path > parameter: > > "Unable to find directory: "C:\documents" > > It's obvious, that the msi did not pass the path enclosed in "..." like > I intended, but instead passed " literally to the called program, > messing up its command line parser. This is somehow strange, because > there are lots of samples around showing ExeCommand attributes with > enclosed " expressions. Either nobody ever actually tried this, or > there is something really weird going on in my machine ... but I cannot > see any obvious reason, the source code above is, in my opinion, > correct, and the symptoms are clear. > > Candle.exe and Light.exe are both 3.0.5419.0. > > Any hints? > > Thanks, > > AL. > > -- > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and > stay ahead of the curve. Join us from November 9-12, 2009. Register > now! http://p.sf.net/sfu/devconf > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > SDL PLC confidential, all rights reserved. > If you are not the intended recipient of this mail SDL requests and > requires that you delete it without acting upon or copying any of its > contents, and we further request that you advise us. > SDL PLC is a public limited company registered in England and Wales. > Registered number: 02675207. > Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 > 7DY, UK. > > > > -- > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Quote-in-quotes problem in ExeCommand, a WiX bug, or am I missing something?
Hi WiX experts, before I wave the "bug" flag, being relatively new to WiX, I am asking you to review this problem, and probably give me advice how to circumvent the following weirdness: my xml is: NOT Installed NOT Installed Since [MyDataPath] does most likely point to a "documents and settings\" subfolder, I enclosed the command line parameter in double quotes by adding ". The installation runs through, but when my program "update.exe" gets executed, it complains about a non-existing path passed via tha /Path parameter: "Unable to find directory: "C:\documents" It's obvious, that the msi did not pass the path enclosed in "..." like I intended, but instead passed " literally to the called program, messing up its command line parser. This is somehow strange, because there are lots of samples around showing ExeCommand attributes with enclosed " expressions. Either nobody ever actually tried this, or there is something really weird going on in my machine ... but I cannot see any obvious reason, the source code above is, in my opinion, correct, and the symptoms are clear. Candle.exe and Light.exe are both 3.0.5419.0. Any hints? Thanks, AL. -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
