问题
I have a standard Visual Studio (2008) application setup project, which generates an msi containing a few files. I noticed however that: 1) When the msi installs and some of the files already exist, it simply silently ignores these files. This is the behaviour that I don't want, because of obvious reasons. 2) When I uninstall the msi, it doesn't delete my main dll file.
How can I fix these two things? Together they make it impossible to automatically upgrade my software.
回答1:
I had the exact same problem and eventually gave up. Getting it to work is a horrible, complicated process involving lots of GUIDs. You'll feel very dirty afterward (assuming you ever get it to work).
My advice is to switch to Inno Setup which is much more suited to people like you and me.
Leave .msi to people who do "corporate rollouts" instead of "installs".
回答2:
Have you incremented the version number in your setup project? Incrementing the version number will also ask you to create a new product id. You should confirm this question with yes.
回答3:
I had a similar looking issue when I was testing overwriting existing files with an MSI - existing older files were not being replaced with newer files in the MSI.
What it was that my newer files which did not overwrite the existing were versioned files (they were DLLs), and the file version numbers had not changed, even though the modified dates were later. As soon as I changed the file version number on the newer files to be a higher version than the existing files, then the existing files got overwritten by the msi.
And then there were other files, like .manifest and .vsto, which were generated by Visual Studio, and these files are unversioned and normally follow installer versioning rules. These all actually relate to a DLL file, and providing a CompanionFile attribute referring to that DLL for each of the .manifest, .vsto, etc. files did the trick.
回答4:
Insofar as not removing all the files, check the reference count under
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs]
If you've used MSIZAP aka the "Windows Installer Cleanup Utility" you've basically put your machine into an unknown state and you'll need to manually remove everything from the registry (in my company we have a utility that removes all known registry entries from the last 10 releases of the product, basically consisting of a 1000 line .reg file and some other tools) before you can reliably test your setup again.
See http://robmensching.com/blog/posts/2009/3/6/More-on-Haacks-Troubleshooting-Windows-MSI-Installers for a bit more information about what happens when you get your machine into an "unsupported state" and how you'll need to manually clean up things or reformat before continuing.
We came across this problem as Installshield automatically defaults to setting components as shared components, so we'd end up with weird reference counting bugs, files left behind, etc, etc. A really ugly solution.
For your upgrades, try doing major upgrades rather than minor upgrades (patches) as this is a lot easier to get your head around when you're first getting into Windows Installer. But first, you'll need to get your app uninstalling correctly, then you can move onto the upgrade. If it won't uninstall properly, it won't upgrade properly.
回答5:
Another option is to include the version number in the application's install folder.
Set Application folder's default location to something like:
[ProgramFilesFolder]\\[ProductName]\\[ProductVersion]
Also set the Setup project's RemovePreviousVersions property to true.
This should delete the old version's folder and create a fresh folder for the new version.
Remember to change the Setup project's version property every time you do a new release.
回答6:
Another option is to uninstall the current application programitally and install the new msi however this will require a custom winforms application
来源：https://stackoverflow.com/questions/674233/how-can-i-make-the-msi-overwrite-old-files