Files not being replaced

[cjb]

We are using the latest version of Installaware and are getting complaints from end users that some files are not being replaced by the installer. The issue seems to affect files randomly since it is seldom the same file being reported as not being replaced.

In particular you can run the install program on 20 PC's and only one PC will not have all files replaced while it worked perfectly on the other 19. Also it never the same PC which is affected. All of the files have a new version number and should be automaticaly replaced. Is there a way to force all files to be replaced or at least verify that the new file has been actually copied to the PC?

It seems to affect Windows 7 and Windows 8 versions of Windows.

How can we fix this? This is a serious problem if we cannot trust the install to work perfectly everytime.

cjb

[FrancescoT]

Dear User,

You forgot to mention some important information about your issue. It is not clear to me, if this happens with a full package update using the Windows installer engine.

This is very strange if true, because the already installed package is first completely un-installed and then the new package version installed.

Then ... due to the randomness with which the error seems to occur, I have a suspect.

Are you sure that those files are not still in use when your package tries to remove it (... as can be a DLL still active under a calling process or not correctly released from)?

Regards.

[cjb]

Here are some additional information.

We use the Native Engine set to TRUE and it is a full install using Installaware 15 (11.19.12). We use the local Files option with a *.bpl and *.dll delete on install option set. The exe files are all version controlled. We terminate the two services ( database and control service) that our application uses before we start the install. At this point there should be no DLL being used by our software since all instances have been terminated. Also in the server and workstation environment we verify and terminate our application if it is running and no local services are installed in the workstation environment but yet some bpl are not being replaced.

The issue seems to be that some DLL's are not released by windows but the install does not replace them on reboot either. We have not been able to successfully specify that if a dll is in use replace on reboot. If you have some code we would be appreciative. Also it is also not replacing some exe files with the newer versions. it seems from our view that for some reason some files are skipped for replacement ( we would like all files replaced on every update).

In one of our test we saw the bpl's deleted from the folder and all but one re-copied to the folder. In another test we saw the files being copied as expected but the exe with the newer version was not replaced. If Windows does have some lock on the file for some reason unknown to us then we would like installaware to replace the file on reboot. For some reason we cannot get it to see that a reboot is required or the reboot does not replace the missed files. The other issue is that the files that are not replaced seem to be random to some degree but it will be that specific file until we re-compile and then the file affected seems to change to another file.

Your help would be appreciated.

cjb

[FrancescoT]

Dear cjb,

could you please try the following simple test?

1- Manually stops those services and just after (without rebooting the system), try to manually delete those files.

Of course you must execute the above steps using a target machine where you experienced the issue.

Let me know if you are able to delete them.

Regards.

[alfrqan]

same issue with me,files are not being replaced by installer...if i delete them will be fine....

[FrancescoT]

Dear Alfrqan,

this topic was started about a possible problem with replacing SERVICE executable files.
do you have the same problem?

Anyway, could you please describe in details the problem you seem to have?

Please note, start a new topic if you are experiencing a different issue.

Regards