none
VS 2010 Setup Project -- Version, Product Code, etc. RRS feed

  • Question

  • This setup behavior is a bit odd.

    The first executing of my .msi setup project successfully adds my new application.  After I've updated the original app I update the setup project to install the updated application. The standard procedure is to add one the Setup Project version number and accept the new generated Product Code.  I have also set the RemovePreviousVersions boolean to true.  By my understand this should ensure that the new version will replace the old existing application, but it doesn't.  The setup wizard runs successfully, but the original application continues to exist and run. (note: It is in the same C:\directory.)

    In my experimenting I have run into a bit of trouble.  By executing the .msi file a second time it allows me to either Repair or Remove the existing app. If I select Remove the .msi deletes the old version, and now I'm able to install my new version of the app.  If my setup project was obsolete it wouldn't allow me to remove the existing app.  Why can't it remove the old version on the first attempt to install my new version of the application.

    I don't want clients to run the Setup project, then run it a second time to delete the old version and finally run the Setup Project a third time to install the new version of the application.  What more to I need to do to merely run the setup application one time?

    Thanks for help on this.  If this is confusing I'll be glad to provide more info, or to straight out what's needed.

    Danny

    Thursday, January 13, 2011 7:07 PM

Answers

  • Hi,

    You are trying to major upgrade the application. You need to make sure that:

    • you have updated the file versions of the files you are updating. Say, if you have an assembly then you need to update the file version by updateing the value in AssemblyFileVersion attribute; for example, [assembly: AssemblyFileVersion("1.0.2.1")]
      Make sure that the version is higher than the previous one. You don't need to update the file version for unchanged files. But for all updated files, you need to update file version; otherwise, they won't get installed.
    • you have updated setup version and accept the new Product Code (which seems you did).
    • rebuild your binaries.

    I hope this helps. Please let me know if it works or not.

    Regards,
    Muhammad Ghaznawi

    • Marked as answer by DannyRC49 Friday, January 14, 2011 7:13 PM
    Friday, January 14, 2011 1:47 AM

All replies

  • Hi,

    You are trying to major upgrade the application. You need to make sure that:

    • you have updated the file versions of the files you are updating. Say, if you have an assembly then you need to update the file version by updateing the value in AssemblyFileVersion attribute; for example, [assembly: AssemblyFileVersion("1.0.2.1")]
      Make sure that the version is higher than the previous one. You don't need to update the file version for unchanged files. But for all updated files, you need to update file version; otherwise, they won't get installed.
    • you have updated setup version and accept the new Product Code (which seems you did).
    • rebuild your binaries.

    I hope this helps. Please let me know if it works or not.

    Regards,
    Muhammad Ghaznawi

    • Marked as answer by DannyRC49 Friday, January 14, 2011 7:13 PM
    Friday, January 14, 2011 1:47 AM
  • Hello Muhammed,

    Thank you so much! It's exciting that changing the AssemblyFileVersion allowed the msi setup project to updating the application on the desktop.

    One question (perhaps I'm crazy but that's not the question) -- I sure that I haven't needed to do update AssemblyFileVersion under VS 2005.  Is it now necessary under VS 2010 for the setup project to update the Primary output (.exe, etc)?

    At any rate, I do appreciate you finding the fix for this problem. 

    Danny

    Friday, January 14, 2011 4:23 PM
  • Visual Studio 2005 setups generated an upgrade that sequenced the RemoveExistingProducts action early in the setup. The upgrade was therefore basically a "remove all the old files and then install all the new ones". This was pretty iffy for somebody with a database installed where an upgrade removed it.

    VS 2008 and later setups generate an upgrade that behaves like a service pack - files don't get replaced unless their file versions have been updated. That's normal - service packs, patches, hotfixes etc have followed this behavior for yeats, and now VS setups do also.


    Phil Wilson
    Friday, January 14, 2011 7:40 PM
  • is it the AssemblyFileVersionAttribute or the AssemblyVersionAttribute that matters when replacing files?
    Tuesday, February 8, 2011 3:31 PM
  • I'd use AssemblyFileVersion. If you don't set AssemblyFileVersion it defaults to AssemblyVersion, so the strict answer to your question is "both", but FileVersion is usually better because cliebt assemblies might require an AssemblyVersion match.
    Phil Wilson
    Wednesday, February 9, 2011 6:53 PM
  • Is that a choice we have somewhere??  i don't see a setting that would seem to allow picking one over the other in the installer.  my main concern is that i have set up all my assemblies with auto updating assembly versions, but that doesn't work with assembly file version, it apparently can't handle the * version specifier to let it update automatically.  So i have removed all the assembly file version attributes and am just letting it use the assembly version for both so it will always be updated for new builds.
    Wednesday, February 9, 2011 7:32 PM
  • No, I'm talking about what the Visual Studio C# (maybe VB too) compiler does. If you don't explicitly specify a File version it will use assembly version, and by "use" I mean "put in the binary's resource's as the file version". Windows doesn't care how the file version got into the file resources as the version, it just uses it for deciding whether to replace the file or not at install time, and that's been the standard rule of file update for years, well before there was a thing called an assembly.  
    Phil Wilson
    Thursday, February 10, 2011 12:41 AM