Ask a questionAsk a question
 

AnswerDeployment .msi to overwrite

  • Tuesday, November 03, 2009 10:07 PMCSharpNooblet Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    I couldn't find a deployment forum, pardon me.

    I have an installer project (Deployment Project) and I cannot seem to effectively do away with the "You must uninstall the previous version prompt." What I mean by "effectively" is that I can get rid of that prompt on running the .msi file produced by changing the Version property (which subsequently changes the ProductCode property). However, the resulting installation does not actually update the application. Features and functionality of the application still indicate that it is the older version.

    Any ideas?

    Thanks.
    • Moved byJialiang Ge [MSFT]MSFTWednesday, November 04, 2009 8:22 AMmove to the setup forum (From:.NET Base Class Library)
    •  

Answers

  • Monday, November 23, 2009 3:14 PMmdfaraz Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    Hi CSharpNooblet,
    I was having the exact problem you reported. With the inputs of Phil, I could resolve the issue. I was too used to VS 2005, where a new setup wud replace all exes of the previous install. Apparently, it has changed in VS 2008.(There should be some documentation on this change somewhere, I never found it, Phil if you know please give the link).
    So what you need to do is, Right click on the project (which has been updated) and click on properties.
    On the Application Tab, Click the Assembly Version button. In the Assembly Version Dialog upgrade the file version to one higher. Save and Rebuild.
    Repeat these stes for all projects that have changed. Build the setup file (after increasing the version by 1 ofcourse) and run the setup, and hopefully, you will see the desired effect ( as I did)!!!
    Thanks a lot Phil for your inputs.


    Faraz
    • Proposed As Answer bymdfaraz Monday, November 23, 2009 3:14 PM
    • Marked As Answer byCSharpNooblet Monday, November 23, 2009 10:29 PM
    •  

All Replies

  • Wednesday, November 04, 2009 10:16 AMWang, JieMSFTUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Hi,

    Could you check your setup project's RemovePreviousVersions Property?

    This property:

    Specifies whether an installer will remove previous versions of an application during installation. If this property is set to True and an earlier version is detected at installation time, the previous version's uninstall function will be called.

    The installer checks UpgradeCode and ProductCode properties to determine whether the earlier version should be removed. The UpgradeCode must be the same for both versions; the ProductCode must be different.

    If you are still having problems, please also check and make sure the executables are also correctly versioned (file version instead of assembly version for managed assemblies) and verify the version number before/after the update.

    Regards,
    Jie
    MSDN Subscriber Support in Forum
    If you have any feedback on our support, please contact msdnmg@microsoft.com
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    If you have any feedback, please tell us.

    The CodeFx Project
    My Blog (in Simplified Chinese)
  • Wednesday, November 04, 2009 10:41 PMCSharpNooblet Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    RemovePreviousVersions is set to true.

    I have built the project after incrementing the version number (from 1.0.0 to 1.0.1). It automatically created a new ProductCode.
    THe installation went through without prompting to uninstall first, however, the .exe file that was produced was not updated.

    Thoughts?
  • Thursday, November 05, 2009 12:22 AMPhilWilsonModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    VS 2008 Setup projects use the same overwrite rules as service packs, hot fixes and so on, which is that if you require a versioned file to be updated you must increment its file version. If you had hundreds of files in your setup this means you just have to change the file versions of those that you've actually made changes to.
    Phil Wilson
  • Thursday, November 05, 2009 1:14 AMCSharpNooblet Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    What does this mean in a practical sense? My project has a "My Project" properties where I can alter the version under the Publish tab. This doesn't seem to be what I want.
    The Primary output for this project within my setup project doesn't have any option to change the version.

    I would think that accomplishing this would be rather straight forward.

    Is it not the case that almost all systems would want installer packages that don't require explicit uninstall of the application before installation can be done?

  • Friday, November 06, 2009 6:49 PMPhilWilsonModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    There are two things going on here:

    1) An upgrade to your existing MSI-based install requires you to increment the version of your setup project. This is in the properties window of the setup project, along with RemovePreviousVersions. This gives you a new product (MSI file) that will upgrade the older version by uninstalling it as the new version is installed. 

    2) Whether individual versioned files get updated is up to you. If they haven't been changed then don't update the file version because they don't need updating. If they have been updated then update file version. In .NET you use AssemblyFileVersion to distinguish from AssemblyVersion. In C++ it's in the resources.

    All this works fine. The Publish tab is about ClickOnce as far as I know, not MSI-based setups.
    Phil Wilson
  • Thursday, November 19, 2009 8:09 PMCSharpNooblet Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    I have incremented the version of the setup project from 1.0.0 to 1.1.0 This automatically creates a new key. Fair enough. I set the RemovePreviousVersion property to True. I think build and run the .msi file. It definitely does not prompt for an uninstall. It installs seamlessly and I can only imagine that it uninstalls the previous version first. However, when I run the executable, my new changes are nowhere to be seen. Any thoughts?
  • Thursday, November 19, 2009 8:19 PMCSharpNooblet Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    I have found the AssemblyFileVersion and FileVersion properties you mentioned.

    My primary output project has this version in it's AssemblyInfo file

    Assembly: AssemblyVersion("1.9.0")>

    The other three assemblies that are also included in the build show these respective versions:

    [assembly: AssemblyVersion("1.8.5.1090")]
    [assembly: AssemblyFileVersion("1.8.5.1090")]

    [assembly: AssemblyVersion("1.0.0.0")]
    [assembly: AssemblyFileVersion("1.0.0.0")]

    [assembly: AssemblyVersion("2.3.1.*")]
    [assembly: AssemblyFileVersion("2.3.1.0")]

    How should I be organizing these values?

    Thanks!
  • Thursday, November 19, 2009 11:43 PMPhilWilsonModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    VS setups don't prompt, they just do the upgrade, just to get that out of the way.
    After you run your setup, what does it say in Add/Remove Programs (or equivalent)? If the version says 1.1.0 then the product updated successfully (and if it had not you would have seen an error and a rollback to 1.0.0).

    If all that worked but you still have the same version of the files on the system that's because the file versions are identical. So ppdate those assemblyfileversion values to something higher.  You don't need to change AssemblyVersion. 
    The general rule is that you update file version when you need it to replace an older version on disk. You change assemblyversion when the assembly is incompatible withg previous versions because it's used when clients bind to it. You don't want an existing client thinking it can bind to an assembly you just shipped if you've changed some of the methods. If your app is entirely self-contained that won't be an issue.
    Phil Wilson
  • Sunday, November 22, 2009 8:40 PMCSharpNooblet Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Hi Phil, thanks for the help.

    I am not sure what to check at this point. As I said, I followed all the instructions for the setup project properties.
    This time around I incremented the AssemblyFileVersion on each project.

    I built the setup project and ran the resulting installer package. It installs fine and seems to take a bit longer, I assume it is uninstalling the previous version as well. When I run the executable, though, none of the changes are applied.

    I am now back to keeping the version the same on the setup project. The installer flashes the "Uninstall Previous Version" prompt once again.

    I would think that updating a previous installation would be simple. What else can I check for?
    Thanks.
  • Monday, November 23, 2009 3:14 PMmdfaraz Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    Hi CSharpNooblet,
    I was having the exact problem you reported. With the inputs of Phil, I could resolve the issue. I was too used to VS 2005, where a new setup wud replace all exes of the previous install. Apparently, it has changed in VS 2008.(There should be some documentation on this change somewhere, I never found it, Phil if you know please give the link).
    So what you need to do is, Right click on the project (which has been updated) and click on properties.
    On the Application Tab, Click the Assembly Version button. In the Assembly Version Dialog upgrade the file version to one higher. Save and Rebuild.
    Repeat these stes for all projects that have changed. Build the setup file (after increasing the version by 1 ofcourse) and run the setup, and hopefully, you will see the desired effect ( as I did)!!!
    Thanks a lot Phil for your inputs.


    Faraz
    • Proposed As Answer bymdfaraz Monday, November 23, 2009 3:14 PM
    • Marked As Answer byCSharpNooblet Monday, November 23, 2009 10:29 PM
    •