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.

Solution 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

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

Solution 3

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.

Solution 4

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

Solution 5

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

View more solutions

Comments

[Craig]

Does this not make the installer think that this is a different product? (Changing the GUID, that is)?

[Bueller]

@cdotlister: I will be honest and let you know that I don't fully understand but this is the way I understand it. The installer has a GUID that is separate from the product being installed. You have to change the GUID in the installer project so it knows you are installing a new version of the product whose GUID hasn't changed. If you do not do this, the installer thinks you are trying to repair the previous version. There are likely nuances I've missed or may be off base on the why it works but it does work. Sorry I can't be more helpful here but perhaps others can or even google.

[Néstor Sánchez A.]

@Craig the UpgradeCode is the GUID used as the common id between different versions (with different ProductId) of the same product.

[PhilDW]

You don't need to increment assembly versions, just file versions. File version defaults to AssemblyVersion, but that screws up clients that are bound to assemblies. Just increment AssemblyFileVersion and you can leave AssemblyVersion alone.

[Gertsen]

This doesn't seem to work for non-exe based products - I tried it with a VSTO addIn for Office, and this didn't solve the problem :-(

[atlantis]

Ah too bad. I finally gave up on VS Setup projects and went with NSIS installer (when I was still working on this project).

[Gertsen]

I found another solution though - make sure all the dll file versions change for each setup package. In my case I changed my solution to use a shared AssemblyInfo file across all VSTO-projects in the solution, and then incrementing the version number each time I make a new setup package. Alternately set AssemblyVersion to auto (1.0.* or similar) And don't set AssemblyFileVersion (forcing it to use the AssemblyVersion). This also changes the version of all dll files, making sure they will be replaced in the setup package.

[Gertsen]

More info on how to setup and use a shared AssemblyInfo file here: weblogs.asp.net/ashishnjain/…

[atlantis]

Cool. Its a shame something as critical as a setup project has to have so many hoops to jump through :|

[RJN]

AssemblyVersion & AssemblyFileVersion of assembly should be changed along with settings you mentioned to make the overwrite happen.