Installer won't overwrite existing app

Question

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.

Answer 1

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.

Answer 2

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

Answer 3

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

Answer 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.

Answer 5

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.

Answer 6

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