Shared files not uninstalled

[afriesen3]

I have an install package with multiple components. A set of files are shared among these components. However, when everything is uninstalled, any file marked as shared is not being removed from the system. Other than marking the file as shared, what must be done to get these files to be removed during uninstall?

I can reproduce the problem:

• 1) Start with a default "Basic Setup" project (called SharedDll)
  2) Add two components (called A and B)
  3) Add a single dll to each component (Dummy.dll), marking the dll as shared for both components

Installing and then uninstalling both components leaves the shared dll on the system.

All of the following MSIcode is as generated by InstallAware:

Code: Select all

DEFINE REGION: Perform Uninstallation
  if Variable REMOVE Equals TRUE
    Comment:  Uninstall product
    Comment:  TO-DO:  Insert any additional uninstall commands here
    Apply Uninstall (get result into variable SUCCESS)
    Set Variable PROGRESS to 100
  else
END REGION
DEFINE REGION: Perform First Time or Maintenance Installation
    Comment:  Install/Re-Install product
    Create Shortcut $SHORTCUTFOLDER$\\Uninstall #TITLE# to $UNINSTALLLINK$
  [OFFLINE CONTENT]
  [DEFINE WEB MEDIA A]
    Get Component SharedDll\\A Selection State into Variable SELECTED
    if Variable SELECTED Equals TRUE
      Install Files Z:\\Temp\\Dummy.dll to $TARGETDIR$ (Shared)
    end
  [DEFINE WEB MEDIA B]
    Get Component Shared Dll\\B Selection State into Variable SELECTED
    If Variable SELECTED Equals TRUE
      Install Files Z:\\Temp\\Dummy.dll to $TARGETDIR$ (Shared)
    end
  [DEFINE WEB MEDIA SharedDll]
    Get Component SharedDll Selected State into Variable SELECTED
    If Variable SELECTED Equals TRUE
    end
    Comment:  TO-DO:  Insert any additional install commands here
  [compiler if Variable BUILDMODE Equals PATCH]
    Apply Patch (get result into variable SUCCESS)
  [compiler else]
    if Variable ADVERTISE Equals TRUE
      Apply Advertise (get result into variable SUCCESS)
    else
      Apply Install (get result into variable SUCCESS)
    end
  [compiler end]
    Set Variable PROGRESS to 100
  end
END REGION

Thanks,

[MichaelNesmith]

Reference counting is probably being damaged in the Windows Installer registry; I'd recommend that you do not install the file twice but only once.

[afriesen3]

Even the simplest example demonstrates this problem. Is this a bug in windows installer or InstallAware? It seems to be an InstallAware bug. I am having Service installation/uninstallation problems as well, which I will submit a separate topic on.

Also, where in the registry is registry counting maintained? The only thing on the net that I can find mentions

Code: Select all

HKLM/Software/Microsoft/Windows/CurrentVersion/SharedDlls

but that is only supposed to be for backward compatability with old installers, not current Windows MSI installers.

Installing only once will require restructuring the entire install and takes me back to basically ground-zero with regard to installation testing, so is not a viable option.

Thanks,

[MichaelNesmith]

Well, I hate to be a bearer of bad news for you, but R&D has its own internal list of priorities for bugs and new features - based on severity and availability of workarounds - in your case, if you're about to demand a fix for this issue, I'd encourage you to not hold your breath

[afriesen3]

I never demanded a fix; that is your own little delusion. I didn't even get an acknowledgment that it is a bug.

That aside, your suggestion doesn't work on a system that has already had the previously shared file installed. Since the install path doesn't change, the reference counting is still apparently hosed.

Where is the reference counting information stored in the registry so that I can attempt to clean it up?

[MichaelNesmith]

You should be able to find out that information from Windows Installer documentation.

Maybe you explicitly didn't demand a fix, but then please help me interpret this item:

Installing only once will require restructuring the entire install and takes me back to basically ground-zero with regard to installation testing, so is not a viable option.

[afriesen3]

Demand is still a strong description (not to mention you are quoting from a support request rather than this thread). Your flippant responses, both in this thread and others is still uncalled for. An acknowledgment that a bug does exist, and a possible time frame of when a fix might be available is certainly a better response than "don't hold your breath". If I know a fix is possible in the near future, that provides testing and implementation options that your response does not. In the absence of a bug, an indication of what the user is doing wrong would suffice.