Introducing automatic updates for Office extensions
Version 8.3 of Add-in Express for Office and .net added support for automatic updates when using ClickTwice – MSI-based web deployment technology (this technology is closely tied with Add-in Express).
Before you use the features described below, make sure your add-in doesn’t contain CheckForMsiUpdates calls!
Creating an add-in installer
You start with creating a setup project as described in section Deploying a per-user Office extension via an MSI installer of the Add-in Express manual. If you deploy a per-machine add-in, see section Deploying a per-machine Office extension via an MSI installer instead.
When the setup project is ready, you publish it using the ClickTwice publish wizard. Note that publishing with ClickTwice creates files, which you need to copy to the location accessible by the users of your add-in; the publisher dialog won’t copy the files for you.
To use automatic updates, click the Preference button (see the screenshot above) and tick the Enable automatic updates flag in the Preferences dialog window:
The Preferences dialog allows choosing these options:
- You may prefer to check for updates when the host application starts or closes.
- Alternatively, updates can be checked in the background in the specified intervals.
Publishing the add-in installer
At this point you can publish the add-in installer. When you do this, Add-in Express creates the MSIPublish folder within the add-in project folder. Now you need to copy all of the files and folders from the MSIPublish folder to the location accessible to end users via the URL specified in the Installation URL field (see the first screenshot).
The files and folders within the MSIPublish folder are described in Files generated by ClickTwice.
The main file is called downloader. If no prerequisites are specified, it downloads the .MSI file from {Installation URL}/{Language code}/{Version} and runs it. If prerequisites are specified, it launches setup.exe located in the prerequisites folder, waits for the prerequisites to get installed; and then downloads and runs the .MSI. The file name of the downloader is set to the name of your project, such as myaddin1.exe.
Installing the add-in
Provide the end user with the URL pointing to {Installation URL}/{Language code}/{Version}/{downloader file name} and let them download and run this file. Starting it installs prerequisites (if specified) and runs the add-in installer.
Creating an update
Modify the add-in project and change its version. Update the setup project and change its version. Create an installer for the updated setup project and publish the installer. Copy all the files from the MSIPublish folder to the location that the users access via the URL specified in the Installation URL field.
Automatic updates
When you publish the add-in, a set of important files is created in folder MSIPublish/{Language code}/{Version}/updater. These files are the updater application and its configuration file. When installing the add-in, the downloader also downloads the updater application; the updater checks for updates as specified by the developer. The settings of the updater application are available for the developer on the Preferences dialog:
When the updater detects an update, it creates an icon in the notification area and displays the balloon tip:
In the screenshot above, you see the icon specified in the Publish dialog.
Clicking the notification icon produces the following dialog (this form is fully customizable via the OnUpdaterUICreate event of the ClickTwice module):
Clicking the Download button downloads the downloader for the new version and starts it. The downloader checks that the host application(s) is closed and starts the installer.
22 Comments
Looks great! Can’t wait to try it out.
One minor thing is to consider – make all windows theme aware. Built-in tools should correspond to the host UI.
Hello Eugene,
Thank you for the suggestion!
Seems a great feature…
It seems great,thank you for your sharing.
I’m sure that many will disagree with me but I really like the idea that Microsoft Office 2016 is running on an auto-update feature, similar to Windows 10. It’s a quite handy feature for us who suffer from short term memory amnesia :)
Hi,
I am just having a small issue, windows is showing ballon tips that Your update is available and when i download, it won’t start automatically.
Is there any property i am missing?
Please respond
Hello Asim,
Is the host application started at this moment? Is the updater icon available in the tray area? What you get if you click (double-click) it? Please send a screenshot(s) and as many details as possible to the support email address; find it {Add-in Express installation folder}\readme.txt.
This is great, except I can’t get passed the signing section of the MSI-based web deployment dialog box when trying to publish. I have a code signing certificate from GoDaddy that I use for all of my applications and have never had an issue. When I click “Select from Store” and select my certificate it gives a popup that says certificate not found in store. When I click “Select from File” and select the .p12 version of my certificate it gives a popup that says “Add-in Express for Microsoft Office and .NET: Arithmetic operation resulted in an overflow.” When I select the .pfx version of my certificate it gives the same popup. When I click “Create New” and make a new certificate I get the same popup when clicking “Publish”. I would really love to use this functionality, please help.
Really strange. What Windows version do you use?
I’m using Windows 7 Pro x64 with Visual Studio Ultimate 2010 and Add-In Express for Office and .Net Standard. I have needed this auto-update functionality for my boss for a while now as he has very extensive macros for Excel and Outlook and he works in various locations and it’s difficult to install updates for him (and he requests macros/changes constantly).
First sentence under “Creating an add-in installer” where you reference another article on the site “Deploying a per-user Office extension via an MSI installer of the Add-in Express manual”. It would be easier for users to find it if you made that a hyperlink to the page: “https://www.add-in-express.com/creating-addins-blog/deploying-peruser-office-extension-msi-installer/”
You have an enormous amount of information on your site and it can be difficult to find specifically what you’re looking for sometimes.
Hello David,
Thank you for pointing us to this omission!
I was able to get this to work finally. It’s amazing, great job!!! Do you know if there is any way to change the icon of the downloader (applicationname.exe) and also the msi installer? It would be great to fully brand a product since end users won’t see an icon for an add-in, so it would be nice to be able to use it during setup at least. I do see the option to provide the icon for the updater that is displayed when an update is posted.
Thank you, David!
You specify the icon in the Icon field; see the very first screenshot on this page. As far as I know, the icon of the .MSI file is specified on the system, not on the file itself.
ok I think this should be the last issue that I’ll run into that I need help with. Inside my solution in the MSIPublish folder there is the version_info.xml file that is created by addin-express publish functionality. the root node of the xml file appears to provide the applicationID, name, and highest published version. Under that, in the applicable language node it lists information for each version that has been published. I am fairly new to publishing and so I think I messed up my project but not sure. I initially published as version 1.0 and everything went well. Then to test, I published a few more versions (1.0.1 and then 1.1.0). Now that I think I’ve got the hang of how it works, I wanted to go back to being on the real version of my project, which is 1.0. The problem is that the first line in the version_info.xml file still shows that the current “version” = 1.1 because that is the highest version that has been used. I’ve set both the assembly version and setup project version to 1.0.0, and I also have completely deleted the MSIPublish folder, as well as making sure that the proper version 1.0 is selected in the publish dialog. No matter what I do it still says the latest version is 1.1. The problem this is causing is that when I publish 1.0.0 and then publish an update as 1.0.1 the updater fails on the client because the xml file is telling it to look for a 1.1 version node that doesn’t exist. Please help.
–
–
–
–
LEW_OutlookMacrosSetup(1.0.0).msi
updater\lew_outlookmacros.service.exe.config.deploy
updater\lew_outlookmacros.service.exe.deploy
updater\lew_outlookmacros.updater.exe.config.deploy
updater\lew_outlookmacros.updater.exe.deploy
–
false
false
true
true
Public
true
Hello David,
In your specific situation, you can just delete the MSIPublish folder and the *.msipublish file; see your add-in’s folder. Also, you can republish versions 1.0.1 and 1.1.0 with the “Enable this version in ‘version_info.xml'” flag cleared; see Preferences. Finally, you can start your product with version 1.2.0 or 2.0.0.
That worked perfect! Thank you so much, the Add-in Express Team are fantastic!
In a future revison, would it be possible for you to add access to one additional setting in your MSI-based web deployment dialog box? Specifically, in the preferences dialog, in the updater section, an option to make the checkbox that asks “do you want to automatically restart this program after the update” be checked by default, or possibly an option to not even display that checkbox and rather to allow the developer to decide if the app is restarted after the update or not. Typically programs that I have used, such as CCleaner, etc…, automatically restart themselves when you elect to allow them to update, and the first thing my boss asked me when I showed him the new installation/update interface was if I could change the default checked state of the checkbox on your dialog. Just a thought.
Just as a thought, it would be useful to be able to change the default checked state of the checkbox on the upgrade dialog that allows the user to elect whether or not to automatically start the application again after it has been updated. The default state is unchecked when it reality the typical scenario is that an end user will more frequently want to restart the app than not to.
Hello David,
Thank you for the suggestion! It is gladly accepted.
I was incorrect when I thought that the version problem I’m having was resolved. I did everything you said, and much more that I probably shouldn’t have done, such as change both the upgrade code and the product code (hoping to just start over). No luck. Even when I publish a higher version, such as 2.0.0 as you suggested, the first line in the version_info.xml file where it lists the application id, version, and name still is showing version 1.1. The version I published (2.0.0) does show up as a child node under the product language, but the updater keeps looking at that first line where is see’s that version 1.1 is the latest version and so it will not download the 2.0.0 version. I have spent countless hours trying to google where that version number is being tracked, to no avail. I’ve scoured the registry and the solution files as well. When I delete everything regarding the publish, something somewhere has to be providing the erroneous version 1.1 value but for the life of me I cannot find it anywhere on my machine. Logically there has to be a way that I can simply reset or delete whatever values were created when I was initially publishing the project so that it will forget all past publishings and just treat the publish as if it were a new first time publish (this is what I was hoping for when I changed the product code and upgrade code). As of right now I have effectively ruined my solution and I cannot figure out how to proceed. I even deleted the setup project and created a new one from scratch.
Hello David,
> Even when I publish a higher version, such as 2.0.0 as you suggested, the first line in the version_info.xml file where it lists the application id, version, and name still is showing version 1.1.
This should be normal if only version_info.xml contains a record for version 2.0.0 and the language is the same on the new and old installations. Could you please send me your version_info.xml using the form at https://www.add-in-express.com/support/askus.php?