Installer won't overwrite existing app

问题:

I have a Visual Studio 2010 solution with 8 projects. It also has a Setup project which I build to create the installation.

It works fine when it's the first installation on a client PC. However, I then modify my project, and build a new Setup, and pass it onto clients. When this happens, the client has to first, manually, uninstall the last installation, and then run the setup.

If they run the setup, without uninstallaing, it seems it doesn't overwrite existing files (exe as well as the dlls). Usually it's just the exe that gets modified. However, it doesn't overwrite it. The version on the client machine seems to stay the same.

Is there a way to force it to overwrite?

Note that when I modify my main application project, I go to the properties of the project, assembly information, and increase the Assembly Version as well as the File Version.

回答1:

The visual studio installer is not the most user friendly compared to commercial products or even WiX if you are after a good level of control over you installation.

When you have a Visual Studio Setup project you have several properties that are involved in the Upgrade process

1) The Upgrade Code - this is the link between installers of the same ilk and you shouldn't change this code needlessly

2) The Version number - strangely only the 1st 3 numbers (major.minor.build) are used for comparison (this is a common mistake that a lot of developers make)

3) The Product Code - As soon as you change the version number VS will prompt you to change this number - do it - if you automate the number change remember to do this as well

4) DetectNewerInstalledVersion - set to True

5) RemovePreviousVersions - set to True

Personally I'd look at using WiX for such a small installation i.e. if you can do it in Visual Studio then the WiX version

My installer for OpenCover looks like this

<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" >

<Product Id="*" Name="OpenCover" Language="1033" Version="!(bind.FileVersion.OPENCOVER_FRAMEWORK_DLL)" 
        Manufacturer="OpenCover @ GitHub" UpgradeCode="2250c3f1-d9ba-44d8-b4db-25f91fe92dc6">

    <Package InstallerVersion="200" Compressed="yes" />

    <Upgrade Id="2250c3f1-d9ba-44d8-b4db-25f91fe92dc6">
        <UpgradeVersion OnlyDetect="no" Property="PREVIOUSFOUND" Minimum="1.0.0.0" IncludeMinimum="yes"
                        Maximum="!(bind.FileVersion.OPENCOVER_FRAMEWORK_DLL)" IncludeMaximum="no" />

        <UpgradeVersion OnlyDetect="yes" Property="NEWERFOUND" Minimum="!(bind.FileVersion.OPENCOVER_FRAMEWORK_DLL)"
                        IncludeMinimum="yes" />
    </Upgrade>

    <Media Id="1" Cabinet="media1.cab" EmbedCab="yes" />

...

</Wix>

I hope you find the above useful

回答2:

In the properties of the setup project, change the version/build numbers. This will prompt you to allow a new GUID to be generated. Doing this tells the installer that you have a new version and will allow the old version of the program to be automatically removed and the new installed by the MSI system.

回答3:

This is an old post but adding this for people who might come looking for an answer.

I ran into this very problem even after following everything given here to the letter. My issue was that the C# program's version will not increment on every build no matter what. Even after I manually edited AssemblyInfo.cs, the generated exe's version would still be 1.0.0.0. As a result, setup won't replace the file.

The workaround is to add a launch condition to the "Primary Output from XYZ Project" (or whatever you want to be overwritten) node of setup project. This causes the installer to delete the file when the newer setup is run. Now when user launches the app, a window appears saying application is being configured, newer files are copied to the app folder and app is launched. This is plain trial and error. I have no clue why it works this way (and I need some coffee after spending the whole night trying to figure this out :)).

1. Right click on your setup project >> View >> Launch Conditions
2. Right click on "Requirements on Target Machine" >> Add File Launch Condition
3. A node ("Search for File1") will appear under "Search Target Machine" and another node ("Condition1") will appear under "Launch Conditions"
4. Click on Search for File1 and change its FileName property to something which is bound to pre-exist (like "Notepad.exe", well almost always)
5. Note that "Folder" is set to "[SystemFolder]" and "Property" is set to "FILEEXISTS1"
6. Now click on Primary Output from XYZ Project or any other node and in the properties window, set "Condition" to "FILEEXISTS1" exactly as it appeared above

回答4:

I also had the problem of the .exe not updating although following the steps above. It would seem that the product version of the .exe does not automatically follow the version number set in the setup properties. For the .exe to be replaced when running the new installers increment the product version as follows:

1) Goto Project Properties > Application > Assembly Information...

2) Increase the Assembly and File version numbers

3) Build the setup again and the install should overwrite the old .exe

Hope this helps someone.

回答5:

AssemblyVersion & AssemblyFileVersion should be incremented for assembly (exe/dll) overwrite along with other settings what @shaun wilde mentioned

回答6:

I had the same problem. The best way to ensure this is to make sure your executable file, i.e. the Application.exe itself has a higher version than the preceeding one.

Just click on the project properties (not the setup project), and set the Application version to a higher one.

回答7:

Refining the answers a little, you must increment the File version to get Windows Installer to overwrite during an update. This is not necessarily the same as incrementing the assembly version as some have indicated. Only the file version needs incrementing, and with managed code you do this with AssemblyFileVersion. The file version defaults to assembly version, but AssemblyFileVersion lets you make them different when you have client assemblies that depend on a specific AssemblyFileVersion.

回答8:

Had similar problems with files not overwriting. Checked version numbers, product/upgrade codes, everything. What finally helped me was this post at MSDN. Specifically the part here, when using Orca to examine the msi file:

I also changed the sequence of RemoveExistingProducts in the >InstallExecuteSequence table from 6550 to 1525 (after InstallExecute to after >InstallInitialize).

Not sure why, but the installer seems to run the uninstall of previous version after it's already installed the new version. Maybe there's a reason for it, but changing it seemed to be the only way I could force my application to upgrade.

If anyone else stumbles across this problem like I have recently, hope this workaround helps.