Converting two distinct installers (before my time) into single mixed.
The new mixed installer will be performing either new, or upgrade type installs (the original single-purposed installers did not keep the msi file
around - and the file organization is slightly different).
On x86 systems it works fine. On 64 bit system, it's mostly there. Problem is....
the older release put three files in sysWow64 directory, and the same three (by name, the dll was a 64-bit build) in system32 directory.
The new release however only needs the three files placed into system32 directory. This does in fact happen. What I want to happen as
a result of the 'upgrade' is a removal of the three files in sysWow64. By empirical evidence (though I'm not sure why), the dll file is
in fact removed from the sysWow64 directory as desired, but the remaining two were left remaining.
I then added a custom rule that would remove
those two file using a VB script. Although the log indicates some awareness of this custom ation script, it doesn't appear that
the script was either called, or worked because the two files are still left remaining.
I have attached the config files for the three installers: x86 only, x64 only and mixed. Also enclosed is the
log-file for the install, and the vb script file.
I don't understand what is governing the removal of the one file, and why the other two are left standing.
any suggestions
Suggested Articles
conversion of distinct 32 & 64 bit installers into single
- Attachments
-
- install.zip
- (40.98 KiB) Downloaded 354 times
Re: conversion of distinct 32 & 64 bit installers into singl
Hello,
I'm not sure why you are encountering this behavior. However, in order to achieve what you want you can add file removal operations, in the "System" folder, for the related files. Also, the file removal operations components should be added to your 64-bit feature in "Organization" page.
Let us know if this helped.
All the best,
Daniel
I'm not sure why you are encountering this behavior. However, in order to achieve what you want you can add file removal operations, in the "System" folder, for the related files. Also, the file removal operations components should be added to your 64-bit feature in "Organization" page.
Let us know if this helped.
All the best,
Daniel
Re: conversion of distinct 32 & 64 bit installers into singl
Thanks for the suggestion, but I figured out why my custom action script was not working.
On another issue... a previous version of the install package (which did not save the MSI file away) places
3 entries in the registry (for the 3 files placed into the system32 directory) at HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/SharedDlls.
The new combined installer (when executed against the older package) installs fine. But when asked to uninstall, it does so,
but it leaves behind the 3 files -- and the 3 registry entries above in 'SharedDlls' remain.
If the new package executes on an untouched system (never having had the old package installed), the 'SharedDlls' entries
go away on uninstall.
Is this an issue due to the new package not having an MSI file to work from for it's uninstall portion of the upgrade process?
On another issue... a previous version of the install package (which did not save the MSI file away) places
3 entries in the registry (for the 3 files placed into the system32 directory) at HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/SharedDlls.
The new combined installer (when executed against the older package) installs fine. But when asked to uninstall, it does so,
but it leaves behind the 3 files -- and the 3 registry entries above in 'SharedDlls' remain.
If the new package executes on an untouched system (never having had the old package installed), the 'SharedDlls' entries
go away on uninstall.
Is this an issue due to the new package not having an MSI file to work from for it's uninstall portion of the upgrade process?
Re: conversion of distinct 32 & 64 bit installers into singl
additional info...
install of version 2.1.1 (3 files + 7 registry entries created) [ the 3 files get placed into the system32 directory, so there is an
increment of the reference count in the SharedDLL registry key
uninstall of version 2.1.1 (all files and registry entries are removed) [ the 3 entries in the SharedDLL registry key are removed,
presumably due to the reference count going to zero.
install of version 2.1.1 (same result as above)
upgrade to version 2.2.0 (with upgrade type to remove old version prior to install -- looking at the log file, the same
actions that reduce the reference count of the 3 files in system32 folder occur)
Then in the install portion of the log file, the same increment of reference counts looks to occur. However,
on inspection, the reference count for two of the three files is at '2', and the remaining file is at a count of '1'.
On uninstall of version 2.2.0, the two files that had been at count of 2, are now count of 1. The file that had
been at count of 1 is now gone.
Also troubling is that all three files in the system32 folder remain, even though the uninstall completed without
issue and no longer appears in the add/remove program control panel dialog.
The zip file contains the the install/de-install logs for 2.1.1,
and the install 2.1.1 followed by upgrade to 2.2.0, followed by de-install of 2.2.0. Screen shot of registry for SharedDLL
with presumed invalid (or at least undesired values)
I don't see what the problem is... any help? Thanks in advance.
install of version 2.1.1 (3 files + 7 registry entries created) [ the 3 files get placed into the system32 directory, so there is an
increment of the reference count in the SharedDLL registry key
uninstall of version 2.1.1 (all files and registry entries are removed) [ the 3 entries in the SharedDLL registry key are removed,
presumably due to the reference count going to zero.
install of version 2.1.1 (same result as above)
upgrade to version 2.2.0 (with upgrade type to remove old version prior to install -- looking at the log file, the same
actions that reduce the reference count of the 3 files in system32 folder occur)
Then in the install portion of the log file, the same increment of reference counts looks to occur. However,
on inspection, the reference count for two of the three files is at '2', and the remaining file is at a count of '1'.
On uninstall of version 2.2.0, the two files that had been at count of 2, are now count of 1. The file that had
been at count of 1 is now gone.
Also troubling is that all three files in the system32 folder remain, even though the uninstall completed without
issue and no longer appears in the add/remove program control panel dialog.
The zip file contains the the install/de-install logs for 2.1.1,
and the install 2.1.1 followed by upgrade to 2.2.0, followed by de-install of 2.2.0. Screen shot of registry for SharedDLL
with presumed invalid (or at least undesired values)
I don't see what the problem is... any help? Thanks in advance.
- Attachments
-
- toAI.zip
- (146.88 KiB) Downloaded 599 times
Re: conversion of distinct 32 & 64 bit installers into singl
Hello,
This may happens if the related file are shared between more programs installation. Please take a look on our "Uninstall leaves behind reference counted files" thread which may be useful for you.
Can you please try to test you scenario (install version 2.1.1, upgrade to 2.2.0 and then uninstall 2.2.0) on a clean machine and see if the behavior still persist?
Also, you can take a look on our "Upgrade an older version of the package" article.
All the best,
Daniel
This may happens if the related file are shared between more programs installation. Please take a look on our "Uninstall leaves behind reference counted files" thread which may be useful for you.
Can you please try to test you scenario (install version 2.1.1, upgrade to 2.2.0 and then uninstall 2.2.0) on a clean machine and see if the behavior still persist?
Also, you can take a look on our "Upgrade an older version of the package" article.
All the best,
Daniel