NMake inline files are always created using ACP. The "1252" in the .idtx
header has no effect on this. However, we must encode the .idt files
using correct charset/codepage regardless the ACP being used on the
building machine.
Signed-off-by: Simon Rozman <simon@rozman.si>
The JScript files are not deployed and used over web. When used locally,
Windows does not check the signature anyway.
Signed-off-by: Simon Rozman <simon@rozman.si>
NMAKE invocations are costly (slow, no-parallel support).
Rather than pinpoint cleaning of each combination of $(PKG), $(LANG),
$(PLAT) and $(CFG) related files, we do the wildcard cleaning of all
$(PKG) related files.
Signed-off-by: Simon Rozman <simon@rozman.si>
The products using Active Setup prior to
18cd389029502ec73da4b62ecdc1792ebdb805f8 upgrade are prone to uninstall
failure because of the missing StubPath value in the registry.
Author the Upgrade table of the package to have those products listed in
a property called `ACTIVESETUPFAULTYPRODUCTS` to inject StubPath in the
registry before RemoveExistingProducts.
Signed-off-by: Simon Rozman <simon@rozman.si>
With ZRCola we renumbered the component GUIDs to group them by platform/
language. However, they are the very same files and calling
RemoveExistingProducts after the upgrade is finished treats those
components as orphaned and removes the just installed files.
Fortunately, if we sequence the RemoveExistingProducts before the
upgrade, it completely removes all components then installs the new
ones. Unfortunately, sequencing RemoveExistingProducts before the
upgrade is sub-optimal on minor upgrades.
This commit extends the InstallExecuteSequence table key to allow the
same custom action appear multiple times and introduces conditioning.
This way the upgrade process can switch between "remove old, install
new" and "install new, remove old" strategy in run-time based on a
condition. The condition is usually a property from the Upgrade table
that is bound to a product upgrade GUID that requires "remove old,
install new" to upgrade properly.
Signed-off-by: Simon Rozman <simon@rozman.si>
MSI has a very simple icon support (it loads only single image out of
available image set, it always loads the first one or the one with the
exactly specified 16/32/48px size...). Therefore GUI icons were
simplified to contain 64x64px image only and MSI controls updated to use
centering/down-scaling.
The maintenance dialog (Change/Repair/Remove) is a bit more convoluted.
We'd need to replace the radio-button selection with a three push-
buttons solution to make things easier. To make things worse, Change and
Repair don't seem to require elevation. Only Remove. This would make the
three push-button solution look ugly. Fortunately, not many people
wonder into the maintenance dialog. Therefore, we shall leave things
there as they are for the time being.
