What exactly do ADXPublisher.exe and the ClickTwice Installer (exe) do?

Add-in Express™ Support Service
That's what is more important than anything else

What exactly do ADXPublisher.exe and the ClickTwice Installer (exe) do?
 
mscheuner




Posts: 67
Joined: 2014-08-04
I'm not entirely clear on what the purpose of both the ADXPublisher.exe and the MyProject.Installer.exe are, in the context of ClickTwice deployment.

What exactly do these two utilities do? What "value" do they add on top of having just a "normal" .MSI installer file, downloading and executing it?

I'm sure they have their purpose and their reason to be - I just can't seem to find much about them in the documentation or in the Learning Center videos. It is explained *how* to use them - but not really WHY, what the benefit / additional capabilities are that we get from using them.
Posted 09 Sep, 2014 10:30:40 Top
Andrei Smolin


Add-in Express team


Posts: 17113
Joined: 2006-05-11
Hello Marc,

Just recently I received a similar question. When answering it, I found out that there's no introduction to ClickTwice in the manual. Below is a draft version of this section. Hope, it answers your question. If not, or, if the answer is incomplete in any way, please (PLEASE!) don't hesitate to point me to the missing details. I desperately need to have some feedback. The more things you don't understand, the more corrections the manual deserves. ))

Introduction to ClickTwice
You start with publishing the installer. You open the Publish dialog to specify the .MSI file to be published, the URL the add-in and updates will be installed from, provide certificate info, select prerequisites and choose options. You can customize the installation process by providing a custom action DLL containing a ClickTwice module; that class provides a programmatic interface to the ClickTwice functionality.

Clicking the Publish button prepares the files required for your add-in to be deployed and places them in a folder structure within the specified folder (local). There are several important files to note:
A bootstrapper, which is generated only if prerequisites are specified. It downloads and installs the prerequisites from the specified URL. If pre-requisites are installed, the setup.exe downloads and runs the downloader (see below).
A downloader; it downloads the .MSI file and runs it.
Am XML file containing version information about updates.

You copy the complete folder structure including the files describing above and prerequisites to a location, which is accessible by the end user via the specified URL. Then you provide the user with a link pointing to the bootstrapper or downloader (depending on whether prerequisites are selected or not). The user clicks the link, the browser downloads the bootstrapper or downloader and starts it, this ends with the downloader downloading the .MSI and running it. Finally, the add-in gets installed.

Publishing an update modifies the XML file and puts the new bootstrapper, downloader and .MSI to separate folders in the same local folder. You copy the folder to the location accessible by end users. When your add-in invokes the CheckForMsiUpdates() method, it downloads the XML file and checks the version information. If there's a new update, it returns the URL of the bootstrapper or downloader. You download the file and start it.


Also, you can search the word "downloader" in the manual. I believe the context will provide extra information about the thing.

Regards from Belarus (GMT+3),

Andrei Smolin
Add-in Express Team Leader
Posted 09 Sep, 2014 10:44:28 Top
mscheuner




Posts: 67
Joined: 2014-08-04
Thanks, Andrei.

I'm still unclear as to what the real need for the *Downloader* is - I understand why you might have a bootstrapper - to download prerequisites and install them - but why do we need a downloader? What's the benefit of using the EXE-based downloader to download and start the MSI file vs. just simply downloading the MSI file (from the "UpdateUrl" returned by "CheckForMsiUpdates()") and then "executing" that MSI directly?

My concern is this: it appears as if the location from where the MSI is going to be downloaded is "hardcoded" and "burned" into the EXE. It's not like the EXE reads that "version.xml" file and then goes to that location given there - the location is burned into the EXE, so if the customer decides to move his installation folder elsewhere in a corporate web site, all those Installer-EXEs must be replaced with new versions (if that's even possible).
Posted 09 Sep, 2014 13:34:31 Top
Andrei Smolin


Add-in Express team


Posts: 17113
Joined: 2006-05-11
Hello Marc,

The downloader uses version_info to find the .MSI to download and run. In addition to the .MSI, it may download other files e.g. custom actions.

There's a method LaunchUpdates. It allows you to specify the URL where the version_info is located. There's a restriction currently: you cannot install prerequisites using this method. Quite soon, we will combine setup.exe (which is created by MSBuild using the GenerateBootstrapper task) and the downloader to a single EXE file and this will solve the problem with installing prerequisites using LaunchUpdates.

Regards from Belarus (GMT+3),

Andrei Smolin
Add-in Express Team Leader
Posted 10 Sep, 2014 03:52:36 Top
mscheuner




Posts: 67
Joined: 2014-08-04
Thanks for your explanations, Andrei.

So if I understand you correctly, I could have something like this:

* a directory on my web server (C:\inetpub\wwwroot\myplugin\installer) that would be fixed, and which would contain the Installer.EXE (which I had to build only once and don't update anymore later on) and the version_info.xml (which gets updated after each deployment build with the latest information)

* a separate virtual directory on that (or another) web server where the actual .MSI are kept (e.g. http://MyDeploymentServer/Builds/MyPlugin/Latest which contains a Myplugin.MSI)

When the user gets the link to the installer at http://MyServer/MyPlugin/Installer/Installer.EXE, the installer reads the "version_info.xml" in its own directory, and finds the link to the MSI which is stored elsewhere, under http://MyDeploymentServer/Builds/MyPlugin/Latest/MyPlugin.msi. The Installer would then download that MSI and run it.

Is this correct?
Posted 10 Sep, 2014 04:27:19 Top
Andrei Smolin


Add-in Express team


Posts: 17113
Joined: 2006-05-11
Hello Marc,

This will work. To switch to using version_info from another location, you will need to publish a new downloader.

Regards from Belarus (GMT+3),

Andrei Smolin
Add-in Express Team Leader
Posted 11 Sep, 2014 10:54:11 Top
mscheuner




Posts: 67
Joined: 2014-08-04
Hello Andrei,

Thanks for your response - unfortunately, it's not working as I had hoped....

I have this setup:

(1) a "landing" page with a link to my installer, e.g. in "http://myserver/myplugin".
That directory on disk contains "MyPlugin.Installer.exe" and "version_info.xml" file

(2) the "version_info.xml" contains these lines:


<application name="MyPlugin.Installer"> 
   <product language="1033"> 
      <version name="0.3.1.0" updateType="directLink" productCode="{GUID}" 
               installationUrl="http://myotherserver/software/myplugin/"> 
         <files msi="MyPluginSetup"> 
             <file>MyPluginSetup.msi</file> 
         </files> 
         <preferences> 
            <showInstallUI>true</showInstallUI> 
            <showUninstallUI>false</showUninstallUI> 
            <webPage/> 
            <showDownloaderWindow>true</showDownloaderWindow> 
            <showRunningApplicationsWarning>true</showRunningApplicationsWarning> 
         </preferences> 
       </version> 
   </product> 
</application>


(3) my other directory, where the actual software install packages reside, is located at "http://myotherserver/software/myplugin". That directory contains:

* subdirectory "1033" for the language of the product
* inside that subdirectory another directory "0.3.1.0" for the version
* that directory contains the "MyPluginSetup.msi" file

I was expecting that if I click on the link to the installer, it would read the "version_info.xml" file in the install location that was defined for it (the "http://myserver/myplugin"), and then from that "version_info.xml", the installer would know to go to "http://myotherserver/software/myplugin/1033/0.3.1.0" and download the ".msi" file contained in that directory and install it.

However: instead of download the file, I get an error from the installer:

Error: There are not files to download in the list of the 'version_info.xml' file


Why does this happen?!?!? Do I need to put the "version_info.xml" somewhere else? Or what else am I missing??
Posted 12 Sep, 2014 01:05:38 Top
Sergey Grischenko


Add-in Express team


Posts: 7224
Joined: 2004-07-05
Hi Marc,

Please use version number with 3 digits only. It should fix the issue.
Posted 12 Sep, 2014 06:38:44 Top
mscheuner




Posts: 67
Joined: 2014-08-04
Hi Sergey,

thanks for your response.

First of all: *why* only support 3-part version numbers? 4-part version numbers are absolutely valid - no?

And secondly: even with three-part version numbers, the error persists. No change :-(
Posted 12 Sep, 2014 10:55:16 Top
Sergey Grischenko


Add-in Express team


Posts: 7224
Joined: 2004-07-05
Hi Marc,

1. The msi installer uses 3 parts in the version number.
2. I will test this scenario on my PC and will let you know about results.
Posted 15 Sep, 2014 03:33:37 Top