2

We have a Visual Studio 2008, Setup and Deployment, Setup Project which installs minimal files and runs some custom actions. We also have several Merge Module Projects that the Setup Project deploys. Each Merge Module has a Module Retargetable Folder with unique sub folders where different components are installed to.

The problem we're experiencing is that during an Uninstall of the Setup Project, files that were deployed by the Setup Project are fully removed from the hard drive; but files that were deployed by the Merge Modules are not removed at all.

Additionally if after uninstalling the files that were deployed by the Merge Module still exist on the hard drive, installing the Setup Project again does not overwrite the files deployed by the Merge Module.

We have to acceptable outcomes:

1) Make it so that the Merge Module deployed files are removed during Uninstall 2) Allow files deployed by the Merge Module to be overwritten during a fresh install

Any thoughts would be appreciated!

danlash
  • 678
  • 1
  • 6
  • 13

2 Answers2

2

I've come across a similar issue in the past, namely due to problem entries in the [HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls] registry key. See if any of the files in your merge module are listed there after uninstall, the reference count might be off and so Windows Installer thinks that the files should remain because they're in use by another application.

Generally this is caused by changing the 'Shared' state of component between setup builds, or by using MSIZAP (aka Windows Installer Cleanup) which doesn't adjust refcounts when purging a package.

saschabeaumont
  • 22,080
  • 4
  • 63
  • 85
  • i checked out the registry. none of our files are listed there. i also checked our merge modules and none of our files are marked as shared or legacy. thanks for the suggestion. – danlash Aug 25 '09 at 13:37
  • I messed around with the DLL and for some reason the count was off. After manually getting it back to an expected state, the problem was resolved. This solved the problem for me, even though it was different than the OPs problem – Timo Apr 05 '22 at 20:03
1

This is maybe not the answer you were hoping for, but it's a thought that might help you out...

Question: Must you really use merge modules? The idea of MSMs is great, but in practice they don't work as well as you might wish.

Instead, embedding full MSIs is often cleaner, because (a) they can successfully install and commit before your app installion begins, (b) they retain control of their own versioning (so you can have them update the files in the next version), (c) you can uninstall them (and all their files) with your uninstallation process, and more. For the Microsoft libraries that they provide as MSMS, there's always an MSI version of the redistributable that you can use instead.

Or did you make the merge modules yourself/ves, for this app? In that case, they would be better as Components in your MSI, as they would follow the same install and uninstall process as the rest of it. And if you have multiple apps that use the same component(s), you can give them the same component IDs and they end up sharing (e.g. when you have 2 apps with a shared component installed and you uninstall one of them, the shared components will remain as long as the other app remains installed).

ewall
  • 27,179
  • 15
  • 70
  • 84
  • true, using chained msi's is a good solution ... we just have a lot invested in merge modules at this point. if worse comes to worst, we'll probably end up using this method. – danlash Aug 25 '09 at 13:36