locked
Non-versioned files won't update in msi install RRS feed

  • Question

  • vs2008 msi deployment project for windows forms:

    I fixed the update install problem for my binary files by changing their version number for each install, but now I find the non-version files are not updating. App.config has no version number and is not over-installing. This is a showstopper bug on the install. It only seems to happen when installing on vista, xp is fine as usual.
    How do you get content or other non-versioned files to update install? I need to force them to overwrite the existing files.


    Thursday, April 3, 2008 4:03 PM

Answers

  • If you want the older Visual Studio 2005 behavior of update via an uninstall of all the existing files followed by an install of all the new ones there is an easy way and a hard way.

     

    The easy way is to change the install location so you don't go on top of the existing files, although a user could change this anyway.

     

    The hard way - you'd need to edit the built MSI file with Orca.

    1) Go to the InstallExecuteSequence table and locate the two actions InstallExecute and RemoveExistingProducts. Note that they are near the end of the sequence.

    2) Delete the row containing InstallExecuteSequence.

    3) Change the Sequence number of RemoveExistingProducts so that it is immediately after InstallInitialize, which probably gives it a sequence number of 1510. The number is not important. Immediately after InstallInitialize IS important.

    4) Save the MSI file.

     

     

    The point about RemoveExistingProducts being at the end of the sequence is that the new files are all installed on top of all the existing files subject to file update rules, then the older product info is removed. That's what makes it an update rather than an upgrade.

    Saturday, April 5, 2008 1:00 AM

All replies

  • This has become very urgent. I can't find any information on this. Is this a non-issue, have I missed something obvious? Do I need to buy a commercial install product or write some sort of additional installation code? It would even help me if one of the mvps could say they don't know the answer...

    Friday, April 4, 2008 1:00 PM
  • The underlying reason is that VS 2008 setup projects do actual updates rather than an uninstall followed by an install, so the Windows Installer update rules apply. These say that an unversioned file will not be updated if its modify date is different from its creation date. This works because MSI sets these dates to be identical when the file is installed, so if the data changes then so does the modify date. So if the unversioned file has been changed after install the setup won't replace it.

    So the first thing to check is the file has been changed.

     

    Friday, April 4, 2008 7:57 PM
  • Thank you for the info.

    1. interesting but it doesn't explain why I can overinstall on xp but not vista. This might be my fault since I don't remember if I edited the config file after install on xp or vista. I now have more info to make a careful study to see what it really does.

    2. I have to have the behavior where the update replaces everything without condition. How do I set that up? I need to be absolutely sure that the .config file is updated.


    Friday, April 4, 2008 9:05 PM
  • If you want the older Visual Studio 2005 behavior of update via an uninstall of all the existing files followed by an install of all the new ones there is an easy way and a hard way.

     

    The easy way is to change the install location so you don't go on top of the existing files, although a user could change this anyway.

     

    The hard way - you'd need to edit the built MSI file with Orca.

    1) Go to the InstallExecuteSequence table and locate the two actions InstallExecute and RemoveExistingProducts. Note that they are near the end of the sequence.

    2) Delete the row containing InstallExecuteSequence.

    3) Change the Sequence number of RemoveExistingProducts so that it is immediately after InstallInitialize, which probably gives it a sequence number of 1510. The number is not important. Immediately after InstallInitialize IS important.

    4) Save the MSI file.

     

     

    The point about RemoveExistingProducts being at the end of the sequence is that the new files are all installed on top of all the existing files subject to file update rules, then the older product info is removed. That's what makes it an update rather than an upgrade.

    Saturday, April 5, 2008 1:00 AM
  • Script here to set RemoveExistingProducts sequence to make VS2008 installer work like VS2005 (i.e. Uninstall first when RemovePreviousVersions is set)

    http://stackoverflow.com/questions/617409/script-to-change-action-sequence-records-in-an-msi

    Easier than mucking around with Orca!
    Friday, March 6, 2009 1:35 AM
  • I find this quite frustrating.  I understand the need for the method of updating versioned files used in VS2008, but why remove support for updating unversioned files as they were in VS2005?  From digging around on the web there are many developers running into problems with this change.  Can't a property be added to a file in a deployment project to specify how it should be handled... ie. as a versioned or unversioned file?

    From what I've been able to determine, this functionality is available in other 3rd party installation wizard software.

    I would appreciate your comments...
    Thursday, August 13, 2009 5:39 PM
  • It's my understanding that the design changed in VS 2008 partly because people do not want to install a product with a database, update that DB for months and then do an upgrade that removes the entire database and replaces it with an empty one. So the question is: In what circumstances do you ship a product containing data, then allow the user to update that data (whether it's a DB or a configuration file or whatever) and then have a product update remove all that updated data? It's also the case that VS 2008 updates now follow the standard update rules that all other updates follow by default (patches, service packs etc)

    Visual Studio setups are designed to be easy to use. If you use a fully-featured tool that offers a lot of support for all the MSI features you'll discover that setups are not as straightforward as you might suspect. Even a trivial detail like exposing the internal Component Guid of each file and registry entry can get you in trouble. 3rd part wizard software isn't the wizard you might think. You'd need to understand what goes on in an MSI install, and what the database tables are for:
    http://msdn.microsoft.com/en-us/library/aa368259(VS.85).aspx 
    and that's just the beginning.  It's a bit like having a wizard that builds a simple device driver for you, and then you want to expand it, and start fiddling with it, then you need to know that if you do the wrong thing you can easily crash or damage a system if you don't follow the rules. VS setup projects keep you awy from all that complexity.  



    Phil Wilson
    Thursday, August 13, 2009 6:27 PM
  • Hi
          i am new for such script mentioned in above link, can you please explain it to me ?
    Thanks in Advance.
    Go Green... Save Mother Earth...
    Tuesday, September 8, 2009 5:06 AM
  • 1) Go to the InstallExecuteSequence table and locate the two actions InstallExecute and RemoveExistingProducts. Note that they are near the end of the sequence.

    2) Delete the row containing InstallExecuteSequence.

    3) Change the Sequence number of RemoveExistingProducts so that it is immediately after InstallInitialize, which probably gives it a sequence number of 1510. The number is not important. Immediately after InstallInitialize IS important.

    4) Save the MSI file.

    Ok these steps are currently what is what is working for me. Is there any way to automate this and make it a post-build step?

     

    Monday, April 12, 2010 5:45 PM
  • That's more or less what the script does, see the link in this thread to stackoverflow.
    Phil Wilson
    Monday, April 12, 2010 7:06 PM