Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
How to upgrade an add-in? RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote
    I'm trying to create an add-in MSI that will work as an upgrade - removing the previous version of the add-in and installing the new version so that the user doesn't manually need to uninstall the previous version before installing.
    So far I haven't been able to get it to work. I'm using WiX and have an <Upgrade> section configured, and here's my results so far:

    1. Don't change the Product GUID or Package GUID, but change the Product Version: New version shows up under available add-ins and after install replaces the previous version, however no actual files get upgraded - presumably because Windows Installer thinks the package hasn't changed.

    2. Change the Package GUID and Version, but not the Product GUID: New version doesn't appear under available add-ins at all. Even worse, there appears to be an ugly bug - when you uninstall the previous version and restart the console, the new version STILL doesn't appear. Oddly, if you change the modification time on the new version it then appears in the available list. This means that in this scenario, if users copy over the updated add-in before removing the old one they might end up in a situation where the new one doesn't appear at all.

    3. Change the Product GUID, Package GUID, and Version: New version shows up and when installed Windows Installer properly uninstalls the old version and installs the new version. Only the new version shows up under Windows Add/Remove programs, BUT both versions now show up under the WHS Installed Add-ins list. It seems that WHS is keeping its own track of installed add-ins and doesn't know that the previous version was uninstalled. If I try to remove one version it uninstalls, but the second version is a "phantom" - trying to remove it just gives an error and it stays in the installed list.

    Can someone provide a walk-through how to create an upgrade install package, or are we forced to tell users to uninstall the old version before installing the new one?
    Even in that scenario there isn't a great way to package the new version - scenario #1 is deceptive as it appears the new version installs correctly (but it doesn't). Scenario #2 can result in the user being unable to install the new version at all due to the bug mentioned, and Scenario #3 leads to phantom entries if the user forgets to uninstall the old version first.


    Thursday, November 29, 2007 3:31 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote
    All I change is the Version property in my <Product> tag as well as the UpgradeCode in the <Product> tag

    Everything else I leave the same.


    For the upgrade code, to make things easier on myself, the first 3 digits of my GUID is the version





    Thursday, November 29, 2007 4:49 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    If I do that it's the same as my scenario #1 - the add-in shows up and can be installed, and WHS thinks it was upgraded, but the new files aren't actually installed. The UpgradeID is actually one thing that shouldn't necessarily change between versions, as it's used to identify previous versions that can be upgraded.

    For now I've settled on changing the ProductID and PackageID, and added some logic that stops the install and displays an error if the add-in is already installed (based on the UpgradeID, which doesn't change).

    This works, but I did run into another issue I had to work around - WHS copies the add-in installer to:
    c:\documents and settings\all users\application data\microsoft\windows home server

    If I used the same installer name for the old and new versions, the new installer would overwrite the old installer when you tried to install it without uninstalling the previous version. Even though the install errors out, you now can't uninstall the previous version because WHS tries to run the uninstall using the "new" installer. The work-around was just to version stamp all the installer executable names so that they don't get overwritten.
    Thursday, November 29, 2007 6:19 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi!

    Regarding to scenario #3: WHS keeps track of the installed addins in the following registry key: "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Home Server\RegisteredAdditions", so removing the key will remove the addin from the list.

    Maybe you can remove the key during the upgrade process?

     

    Regards, Alex

    Thursday, November 29, 2007 6:42 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I was interested in doing an auto upgrade/patch process, but with the Add-In DLL(s) loaded by the console it seems pretty problematic. Has anyone else looked into this possibility?

     

    Monday, January 14, 2008 7:02 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I was also thinking in integrating an update option into my addin (the current uninstall/install scenario is very uncomfortable) and I think that as long as the console remains open, the DLL will be locked.

    So I thought about downloading the new files from an update server, placing it in a temp directory, closing the console and running an external exe that copys the new files to the right places.

    This would avoid the problems with msi files copied to the app-directory or the keys in the registry....

     

    What are your thoughts?

     

    Regards, Alex

    Tuesday, January 15, 2008 8:56 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I think that all we are left with unless there are some methods in one of the WHS SDK DLLs that I'm not aware off.

    Have you seen a console shutdown method in the SDK?

     

    Circumventing the WHS add-in install/updates/patch process might cause problems, but having an auto updating app is a must. Once the console is down, do you see an issues with just running an msi from the external app? The wix based installers are so convenient.

     

    Tuesday, January 15, 2008 3:53 PM