views:

434

answers:

3

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!

+1  A: 

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
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
A: 

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.

sascha
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
A: 

Question:

Can anybody give a idea, Why do we go for Merge Module instead of Creating a Shared Component for that file. Thanks in Advance.

Prem
a merge module allows an entire setup project to be re-used by multiple msi projects. think of you how you create a reusable code library and then have several projects reference it. merge modules allow the same sort of thing... but they also cause some pain. i would recommend using chained msi's instead.
danlash

related questions