32

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.

EvilTeach
  • 28,120
  • 21
  • 85
  • 141
Craig
  • 18,074
  • 38
  • 147
  • 248
  • There is a discussion about this here: http://stackoverflow.com/questions/6307241/is-there-a-way-to-ensure-an-msi-installer-updates-the-exe-file-every-time/6309158#6309158 – Cosmin Jun 11 '11 at 07:41
  • @Craig Did you get any solution regarding how to achieve it? – Sivaram Boina Feb 27 '19 at 10:19

9 Answers9

38

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

Shaun Wilde
  • 8,228
  • 4
  • 36
  • 56
  • 4
    AssemblyVersion & AssemblyFileVersion of assembly should be changed along with settings you mentioned to make the overwrite happen. – RJN Mar 22 '18 at 07:16
7

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.

Bueller
  • 2,336
  • 17
  • 11
  • Does this not make the installer think that this is a different product? (Changing the GUID, that is)? – Craig Jun 21 '11 at 21:23
  • 1
    @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. – Bueller Jun 22 '11 at 02:37
  • 1
    @Craig the UpgradeCode is the GUID used as the common id between different versions (with different ProductId) of the same product. – Néstor Sánchez A. Apr 03 '12 at 18:10
5

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.

Wally Cloud
  • 81
  • 1
  • 4
  • 1
    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. – PhilDW Jun 23 '15 at 18:26
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
Community
  • 1
  • 1
atlantis
  • 817
  • 1
  • 10
  • 16
  • 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 :-( – Gertsen Mar 15 '16 at 15:40
  • Ah too bad. I finally gave up on VS Setup projects and went with NSIS installer (when I was still working on this project). – atlantis Mar 16 '16 at 03:13
  • 3
    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 Mar 16 '16 at 12:28
  • 1
    More info on how to setup and use a shared AssemblyInfo file here: http://weblogs.asp.net/ashishnjain/sharing-assembly-version-across-projects-in-a-solution – Gertsen Mar 16 '16 at 12:29
  • 1
    Cool. Its a shame something as critical as a setup project has to have so many hoops to jump through :| – atlantis Mar 17 '16 at 05:46
3

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

RJN
  • 696
  • 8
  • 17
1

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.

Jeremy L
  • 321
  • 3
  • 7
  • I tried this, but for me the file that was not updating is now not present at all. I am using Visual Studio 2022 version. – shadowsora Jan 12 '23 at 07:22
0

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.

Mnyikka
  • 1,223
  • 17
  • 12
0

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.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
0
  • After a long R&D, I found the solution:

Issue I faced:

  1. Whenever I was installing a new version of the tool from my local, is not updating the existing tool (checked in control panel), and installing a new version for the same tool.

Cause:

  1. Unable to map my locally published tool version to Live location's version.

Solution:

  1. Please insure, you are having the latest published copy of the tool on the live drive.

Note: If you have tried all the possible ways and still not fund the solution, try it also.

lalit pant
  • 39
  • 3