After uninstallation, some files are not removed. Why not?

There may be various causes for this, the most common ones being shared files and files that are created after installation.

Shared files

A shared file is one that is (potentially) used by two or more applications; common examples are the Windows system files and ActiveX controls. To ensure that a shared file is not removed prematurely, the system maintains a SharedDlls reference count for each shared file. This reference count is incremented each time an application is added that uses the file; it is decremented when the application is removed. Only when the reference count reaches 0, it is safe to physically remove the file from the system.

Tarma QuickInstall adheres to this scheme and will not remove a shared file unless its reference count indicates that it is safe to do so. (To mark a file as being shared, you set its Sharing option in the Installation File Settings pane.) However, the reference counting scheme has some weaknesses:

1. If you install an application with shared files twice without intervening uninstallation, the reference count will be one too high. As a result, the shared files will appear to be in use and are not removed if you then uninstall the application. At that point, a second uninstall is no longer possible, because the rest of the application (including the uninstaller with its installation database) has been removed.

This problem is not unique to Tarma QuickInstall; it affects all installation programs that use reference counts. The solution is to always uninstall the application before installing it again. However, it is a fairly harmless problem in the sense that it doesn't prevent other applications from functioning properly; it only wastes some disk space.

2. The opposite happens if files are shared but their reference counts are not properly maintained, as frequently happens with popular third-party controls that are used by many different applications. This may cause the file to appear unreferenced and thus lead to its removal, while in reality at least one other application still requires it.

This problem is in more serious than the previous one, because it may cause one or more applications to malfunction due to missing files.

To follow the strict reference counting scheme, you should set the Sharing option in the Installation file settings of each shared file to Trusted reference count. This indicates that you know that the reference count will always be properly maintained, which is appropriate if the shared files are under your (or your company's) strict control. For example, this might apply to files that are shared among several of your own products, but not used by other vendors.

If on the other hand you do not have this degree of control over the shared files, it is more appropriate to set the Sharing option in the Installation File Settings of each shared file to Untrusted reference count. In this case, Tarma QuickInstall applies an additional rule: only remove a file if its reference count drops to 0 and it was originally installed by Tarma QuickInstall. This may occasionally cause files to be left behind (problem 1), but it prevents the greater evil of breaking other applications (problem 2).

Finally, if you install your file in a folder that typically contains shared files, such as the Windows or System folders (<WinDir> and <WinSysDir>, respectively), but you know for certain that your file is not shared, you can set the Sharing option in the Installation file settings of the file to Not shared. In that case, Tarma QuickInstall will not maintain a reference count for the file and will simply remove the file without further ado during uninstallation. Note that you might get a diagnostic message when you build the project if you use this option; you should use your own judgement to decide if the situation is safe.

Files created after installation

Another common cause for stray files is that they are created by your application after installation. In that case, Tarma QuickInstall doesn't know about them and also doesn't know that they should be removed during uninstallation. However, this problem can be resolved; see Uninstalling Files Created by the Application for information on how to do this.

Other causes

Other reasons that may cause files to be left behind include:

• The file is in use during uninstallation. In that case, Tarma QuickInstall automatically schedules the file for removal during the next system restart, but until that restart the file remains on the customer's computer.
• Access to the file is denied. This may be caused by insufficient privileges, or because the file resides on a network share that is read-only to the customer. To resolve this, you could try checking the Require Administrator rights on the Installation page if you haven't done so already, but this cannot solve all access denied problems.
• The file is not marked for uninstallation. This may be obvious, but it's still worth checking: make sure that the Uninstall action box is checked in the file's Installation file settings pane. If it is not, Tarma QuickInstall assumes that the file should be left behind and will not try to remove it.