Integration of dcUpdater with Nullsoft Installer

[owenduffy]

Mouser,

Some ideas...

I was interested in facilitating use of dcUpdater as part of my product installation. The path I chose with NSI is described below.

Firstly, my package makefile creates a dcupdate.xml file during the setup package build process. This will be loaded on the distribution web site along with the setup file. The makefile also generates a .dcupdate file for the application and which is included in the setup package for installation in the application program directory.

The nsi script writes a file informing dcUpdater of the location of the product program directory, here is an example for the product MyApp.

;register MyApp with dcUpdater
SetShellVarContext all
FileOpen $0 $APPDATA\DonationCoder\DcUpdater\RedirectFiles\MyApp.dcupdateredirect w
FileWrite $0 "$INSTDIR"
FileClose $0
SetShellVarContext current

(This is possibly what the helper app does?)

My application checks for existence of dcUpdater by looking at the dcUpdater uninstall info at registry key HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\DcUpdater_is1 and if it is installed, adds a function to launch MyApp.dcUpdate from my application.

Invoking dcUpdater from the program menu will show MyApp along with the other registered applications because it has been registered by the install script.

Mouser, is any part of this scheme incompatible with the future for dcUpdater.

I considered whether to create the directory $APPDATA\DonationCoder\DcUpdater\RedirectFiles if it didn't exist, and so register for the future... but I elected to not do so at this point. It would not be difficult to extend the script to make sure the directory exists so that the file is written in all cases.

It would be nice if there was a feature to say right click an application in dcUpdater and get a menu option "register this application". (If you are thinking it must be registered to be in the list, no, when I launch MyApp.dcUpdate, MyApp is in the list of one whether it is registered or not.)

Owen

PS: dcUpdater 1.23.01 has a problem with dates in dd/mm/yyyy localisations - some dates don't show up, perhaps because they are regarded as invalid.

[mouser]

cool 

you surmised exactly what the helper does when it registers a new application.  your steps for doing that and checking for existence of dcupdater are valid.

it probably should always create that directory and put itself there, so that if your program is installed, and THEN the dcupdater is installed, it will still find it.

i should say that the small dcuhelper.exe will create this entry when launched, and will also direct the user to the dcupdater website, so really you can use the dcuhelper.exe to do this work -- both to register the application and launch the updater or tell people about how to get updater.

PS: dcUpdater 1.23.01 has a problem with dates in dd/mm/yyyy localisations - some dates don't show up, perhaps because they are regarded as invalid.

you mean in the display window its handling them wrong? or in what way is it doing something wrong?

[owenduffy]

it probably should always create that directory and put itself there, so that if your program is installed, and THEN the dcupdater is installed, it will still find it.

-mouser (February 28, 2008, 09:10 AM)

Ok, if you are not going to clobber it, that is fine, I will write it just in case!

Here is the tested changed NSI script segment for my app named FSC:

  ;register FSC with dcUpdater
  SetShellVarContext all
  CreateDirectory $APPDATA\DonationCoder\DcUpdater\RedirectFiles
  FileOpen $0 $APPDATA\DonationCoder\DcUpdater\RedirectFiles\FSC.dcupdateredirect w
  FileWrite $0 "$INSTDIR"
  FileClose $0
  SetShellVarContext current
  IfErrors +1


The uninstall section should also contain:
  Delete $APPDATA\DonationCoder\DcUpdater\RedirectFiles\FSC.dcupdateredirect


Owen

[mouser]

cool.