Using Adv. Inst. 8.3.
Our projects have been upgraded from 8.2.
Our installer is set to be per machine when admin access is available.
We have created an update of our application. The updater helper runs correctly and downloads and starts the installation of the update.
The update installer runs and removes the previous version (except for the desktop shortcut).
But then when it is trying to finish placing the new files for the updated version, it fails with this error:
The installer has insufficient privileges to access this directory: C:\Program Files (x86)\MyProduct\. The installation cannot continue. Log in as administrator or contact your system administrator.
However, the user IS logged in as administrator.
The location of the original installation and the update are the same (unchanged from default), and both were run with admin access.
The updater MSI finishes successfully if it is run when the earlier version is not installed.
This situation has rendered our updater useless and we are not sure what to do to fix it. This pair of installers is based on a previous set that worked correctly under this setup.
Suggested Articles
Re: Win 7 per-machine update fails
Hi,
I remember encountering this situation some time ago when an user had custom actions in the package which were registering and unregistering,
i.e. during install and uninstall, some DLL files. What happened in that case was that during an upgrade, the old version was removed and the custom
action which handled the unregister operation of the DLL was run. After running this custom action the OS kept open a handle to the installation folder,
and this prevented the new installed to write in that location, even if the package was running elevated, i.e. with admin privileges.
Does your package has custom actions resembling with the above situation or something else?
Regards,
Bogdan
I remember encountering this situation some time ago when an user had custom actions in the package which were registering and unregistering,
i.e. during install and uninstall, some DLL files. What happened in that case was that during an upgrade, the old version was removed and the custom
action which handled the unregister operation of the DLL was run. After running this custom action the OS kept open a handle to the installation folder,
and this prevented the new installed to write in that location, even if the package was running elevated, i.e. with admin privileges.
Does your package has custom actions resembling with the above situation or something else?
Regards,
Bogdan
Re: Win 7 per-machine update fails
Thanks for the quick reply. We don't have any custom actions. We do have Flash Player Plugin installed from a URL to Adobe as a Prerequisite. We also are including the MS Visual Studio Redistro package as a local installation side-by-side with the main application executable. For that, we aren't doing anything special in the Advanced Installer project -- the VS Redistro is just included in the application folder and our executable is compiled to use the side-by-side version. Could that still be causing trouble with the registry? (It didn't used to).
Re: Win 7 per-machine update fails
Hi,
I'm not sure if MS Visual Studio Redistro is the problem. Can you please send me by by e-mail (support at advancedinstaller dot com) download links for your packages,
current version and the one being upgraded, so I can test them on my machines, and also the .aip files, so I can easily analyze their settings?
Regards,
Bogdan
I'm not sure if MS Visual Studio Redistro is the problem. Can you please send me by by e-mail (support at advancedinstaller dot com) download links for your packages,
current version and the one being upgraded, so I can test them on my machines, and also the .aip files, so I can easily analyze their settings?
Regards,
Bogdan
Re: Win 7 per-machine update fails
Hi,
It seems the problem appears because a handle remains open for the installation folder. The handle is being kept open by our removal operations, which you have set on your folders.
The solution is to disable the file removal operation in the old version, build the MSI, with files outside, and recache it as presented in this article when deploying the new version. Adding the old MSI in the new one, in order to perform the recaching, will increase the size with only a couple of kilobytes, as you will not include and the installation files.
We shall continue investigating this to see why our removal support is keeping the handler open, thank you for bringing it to our attention.
Regards,
Bogdan
It seems the problem appears because a handle remains open for the installation folder. The handle is being kept open by our removal operations, which you have set on your folders.
The solution is to disable the file removal operation in the old version, build the MSI, with files outside, and recache it as presented in this article when deploying the new version. Adding the old MSI in the new one, in order to perform the recaching, will increase the size with only a couple of kilobytes, as you will not include and the installation files.
We shall continue investigating this to see why our removal support is keeping the handler open, thank you for bringing it to our attention.
Regards,
Bogdan