How to update an add-in? RRS feed

  • Question

  • Hi!

    I'm working on an add-in for WHS. While I expected to spend quite some time on the add-in itself, it turned out to be much simpler than I thought.

    The installer otoh is surprisingly hard to do. So here's my issue: how can I update an installed add-in from within the WHS Console? As the add-in is being used by that very console, it fails replacing the .dll file during the update. Is the only way to do the update have the user uninstall it first, then re-install the new, updated version? No way to have a simple one click update?


    Wednesday, February 18, 2009 11:04 AM

All replies

  • You uninstall the old version, then install the new version. As you've found, because the DLL(s) used by the add-in are loaded you can't replace them. If your add-in relies on persistent settings, the right place for them is (probably) in a file in an application folder.
    I'm not on the WHS team, I just post a lot. :)
    Wednesday, February 18, 2009 1:12 PM
  • Thanks Ken!

    This means: uninstall, restart console, install, restart console?
    Wednesday, February 18, 2009 1:21 PM
  • The restarts are forced by the uninstall/reinstall, but yes. :)
    I'm not on the WHS team, I just post a lot. :)
    Wednesday, February 18, 2009 4:18 PM
  • Hey Michael,

    I'm going to be releasing a product that allows you to do exactly this.  I wrote a sophisticated prototype last spring that does exactly what you want, and I'm in the process of enhancing it now, and productizing it.  I could probably havea  beta in a week or two, less if no customer issues arise between now and then (wishful thinking ;-).

    The key is you don't go through the add-in manager, you place some sort of "Update" button or similar within your add-in itself (or some other auto-update type mechanism if desired, or a combintion of both). 

    What I did in my prototype is my add-in actually scanned my website for an updated msi, and if found, dynamically display and "an update is available" along with Update button.  If the user clicked, the add-in managed the download.  Alternatively, the user could browse for the updated MSI directly from the add-in.  Through a lot of appdomain trickery of a generic host add-in, suffice it to say at the end of the day the add-in can be unloaded, updated, and reloaded, all without shutting down the console, and all in place.  It's actually quite elegant.  The trick is the add-in, as WHS sees it, is just as thin host that knows how to use appdomains and msi.  It never actually unloads.  But the *actual* add-in unloads, updates, and reloads.

    In the product I'm leaving it up to the add-in developer how the update is sourced, whereas in my prototype this was hardcoded.  If he wants his add-in to manage the locating and sourcing of the update itself, it can, and can programmatically give it to the host to update.  If he wants the program the host where to look for it and to even have it download it in a background thread, he can.  Or if he wants a mixed-mode where the add-in drives the user interface, but delegates to the host to handle the actual MSI sourcing in the background, it will.  By combining these three, if an add-in wants to expose Windows Update type flexibility to how updates are done, it can.  It's up to the add-in author to make it as simple or as complex as they want.  The add-in will always present the update UI, but it can be a user-driven UI, or a UI that responds to events from the host, or a combination of both.  Of course, while the msi is exactly executing after the add-in has been unloaded, the host shows the progress in it's own UI.

    To make this really robust and work well in all instances it requires some potentially advanced MSI work, but it's doable.  The thing I'm working on now is to make the installer smart enough so that if run directly, it delegates the update to the existing add-in, and terminates gracefully.  I have this working, but I'm trying to find a nice, elegant method that is easily reused at a level other than all of these custom actions.   The problem is custom actions are done differently with different MSI products / technologies (IS vs. VS vs. Wise vs. Wix, etc.), and I'm assuming most add-in developers aren't MSI experts.  So, my current approach is I'm basically going to provide a MSM that bundles the host control and all of these custom actions so that your installer will always do the right thing without having to know anything about the host add-in concept.  Then there are (so far) 4 MSI parameters that your MSI can set which drives how the MSM handles updates.  That's the theory anyway...still working on it. ;-)

    The WHS team could have easily implemented a similar framework as this in WHS, but didn't for one obvious reason: KISS.  I'm striving to make this as dirt simple to use as possible, and iI think it will be, but it still requires (at a minimum):

    - adding an MSM to your installer
    - setting at least one of the variables consumed by the MSM in your MSI (the rest all have valid defaults)
    - add a reference to my library
    - add and implement a second interface implementation onto your console and settings class implementations (for maximum control)
    - derive from my console and settings abstract base classes, which implement these interfaces with default behavior that you can override as necessary (for mimum integration effort, but less control)

    If MS had implemented this, they could have made it a good bit cleaner, but not much simpler.  The separate update interfaces could be queried to determine how the add-in wants to manage updates, and as such the whole ugliness I'm now fighting with MSM's wouldn't be an issue, since all of that metadata could be provided by the add-in itself, and queried from the console.  The MSM would have no files to install, since they would be part of WHS itself.  It simply would not be needed.  In fact, the same shadowing mechanism used in ASP.Net host could have been used here (the same principles; not the same code ;-).

    But at the end of the day it would still have made things more complicated.  Plus there is only so much you can get into a v1 product, and this really isn't that important compared to other things that are missing that affects *users*, not just developers.

    I have a sneaking suspicion that WHS 2.0 will have something like this.  But it looks like it's not coming for PP2.  I hope I'm wrong, as I think this will be quite marketable, and am sick of MS making my api's / components worthless overnight. ;-)


    Thursday, February 26, 2009 2:27 AM