Page 1 of 1
Patch installs dual copy
Posted: Tue Apr 07, 2009 8:52 am
by Piet
I've seen a similar (abandoned) thread without the problem being resolved, so I'm starting this one from scratch.
I use IA8 Studio and cannot get a patch to use the same install dir and startmenu shortcut as the original installation. My modified version of the template:
[compiler if Variable BUILDMODE not Equals PATCH]
Comment: First Time Install
Set Variable TARGETDIR to $PROGRAMFILES$\\MyCompany\\MyApp
Set Variable STARTMENU to MyApp
[compiler end]
The Product Name ($TITLE$) includes the version: MyApp v1.0
Normal installation works like a charm, but when I try to patch, the patch always reverts to what I assume is IAs default values:
TARGETDIR is always set to: $PROGRAMFILES$\\$TITLE$
STARTMENU is always set to: $TITLE$
I end up with 2 installations (files, startmenu, registry), except in Add/Remove. "Remove" removes the patch version, except for an empty Startmenu item. The original installation remains, except desktop shortcuts, which are removed with the patch.
Any help would be greatly appreciated!
Piet
Posted: Tue Apr 07, 2009 6:01 pm
by MichaelNesmith
These variable values are automatically saved and reloaded so this problem does not occur. Try to show messageboxes in the patch install which print out these variable values, so we can see if that mechanism is working first.
Posted: Tue Apr 07, 2009 6:17 pm
by MichaelNesmith
This is unable to reproduce, by the way. Tried with a patch running on a base setup installed to a custom folder and the default folders were never used.
Posted: Wed Apr 08, 2009 2:11 am
by Piet
Thanks for the quick response, Michael.
I've added messages as per your suggestion, one just before the Welcome dialog and one just before Apply patch:
[compiler if Variable BUILDMODE Equals PATCH]
MessageBox: Patch. Before apply, Startmenu: STARTMENU$$NEWLINE$Targetdir: $TARGETDIR$
Apply Patch (get result into variable SUCCESS)
[compiler else]
Both give TARGETDIR as $PROGRAMFILES$\\$TITLE$ and STARTMENU as $TITLE$.
I assume I have an incorrect setting somewhere. I've tried other combinations, but my usual compiler settings are: Reduce MSI file and registry component count and Stable identifiers. Output settings: Change revision code automatically. Patch: Include whole files only. My base build is uncompressed for CD. I changed the Product Name from MyAPP v1.0 to MyApp v1.0.1 for the patch (also Product Version), though I have also tried with the same name and version.
In the startmenu I have MyApp and MyApp v1.0.1 after the patch, but in Add/Remove I only have MyApp v1.0, which removes the v1.0.1 shortcuts and files when "Remove" is selected!
Piet
Posted: Wed Apr 08, 2009 5:27 am
by Piet
I have tried with a fresh Basic Setup and got the same results. Only change to basic setup was to modify Targetdir section:
[compiler if Variable BUILDMODE not Equals PATCH]
Comment: First Time Install
Set Variable TARGETDIR to $PROGRAMFILES$\\MyCompany\\MyApp
Set Variable STARTMENU to MyApp
[compiler end]
and to add a message to display real target dir. The installation installs 1 file. The patch (added version to Product Name) adds a file.
Posted: Tue Jul 14, 2009 8:42 pm
by amvbsd
Hi,
I'm having the same problem. I've checked my script and there is nothing out of the ordinary in it. TARGETDIR is set only one time to $PROGRAMFILES$\\MyCompany\\MyApp. Installation runs fine. But patches install to $PROGRAMFILES$\\$TITLE$. Perhaps it has to do with the localization of the setup? Could it be affecting how TARGETDIR is read when the patch is run?
What I see in common with Piet's tests is that the original TARGETDIR has a subfolder in it. Is this not being handled correctly by IA? I'm using IA9 (Build Moya.sp1.070409).
Also, the InstallLocation key in HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\$TITLE$ correctly displays the location $PROGRAMFILES$\\MyCompany\\MyApp. From where does IA gets the value of TARGETDIR when running in Patch mode, to check if the value was saved correctly in the first place?
Thanks in advance for any assistance in solving this issue.
Arturo.
Posted: Wed Jul 15, 2009 6:05 am
by MichaelNesmith
Hi Arturo,
From your description it sounds like localization might be a culprit. Check these pre-defined compiler variables for help, or fix the Set Variable localizations:
#LOCMODE#: Controls how localizations are applied at runtime. This compiler variable has impact on script localizations only, and has no effect on dialogs or shared strings:
If VARSONLY, the only localizations that are applied to a running setup are those for Localization Variable commands, even if other commands have been localized. This helps prevent incorrect and/or unintentional translations of other script commands from breaking a localized setup at runtime.
If NEWONLY, localizations for all commands are applied to a running setup, except commands which have not been localized yet and remain with older default strings, protecting elements which may have since been updated in the script. This helps prevent default values used in unlocalized commands from overwriting the newer values which may have since been changed in the script.
Note: For this option to have effect with old setups, add the file translations.Original from your translation export folder to your setup as a support file. New setups will automatically have this file.
With any other value, all localizations are unconditionally applied.
Posted: Wed Jul 15, 2009 8:00 pm
by amvbsd
Hello, Michael,
I removed all the translations from the setup and used the default English language. However, the problem persisted. The only way I could get the patches to use the correct TARGETDIR was to set the compiler variable LOADOLDDATA to true.
I guess most if not all of the times users will be installing upgrades (either full or patches) so using LOADOLDDATA=TRUE should not cause any usability confusions for them.
Best regards,
Arturo.