Messages

26

DcUpdater / Allocation of .dcupdate namespace to user.

« on: February 28, 2008, 03:32 AM »

Mouser,

Have you though of facilitating end user use of the .dcupdate file by reserving a part of the namespace for the user to allocate knowing nothing that you do will trample over it or be ruined by uncoordinated content.

For example, a sub item called "user" in which all user entities are mapped would achieve that end. dcUpdate would just ignore that part of the xml tree, and the user could use it as he wishes.

Perhaps it would be wise to declare a rule on the maximum size of the .dcupdate file, perhaps 10k would exceed reasonable needs.

Cheers
Owen

27

DcUpdater / suggestion: web path changes

« on: February 28, 2008, 03:27 AM »

Mouser,

We all dread needing to change the web site that hosts our update and support pages for an application.

I suggest that it would be useful if the dcupdate.xml file included in a standard way, a url for the support directory.

eg:

<?xml version="1.0"?>
<root>
<Program_Version>0.0.2</Program_Version>
<Program_Release_Day>0</Program_Release_Day>
<Program_Release_Month>0</Program_Release_Month>
<Program_Release_Year>0</Program_Release_Year>
<VersionFileRemote>http://www.mysite.net/myapp/dcupdate.xml</VersionFileRemote>
... etc
</root>

Further, that when dcUpdater reads the file and finds the 'new' entities, that it updates the application's .dcupdate file for the new url for all such entities that do not match so that dcUpdater can automatically adjust to the new site. This would be most effective if dcUpdater was launched automatically on each boot, or periodically so the new site was likely to be captured before the old site shuts down.

Do you understand what I mean?

Owen

28

DcUpdater / Integration of dcUpdater with Nullsoft Installer

« on: February 28, 2008, 02:58 AM »

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.

29

DcUpdater / Trials...

« on: September 06, 2007, 08:03 PM »

Mouser,

I have just had a little play with DCUPDATER, trying to integrate it into one of my apps.

Some observations:
The help file shows an example for the web version file that is different to one of your apps which sets the items within a <root> section.

I spent a lot of time trying to work out why my release date didn't show in dcupdater... but it looks like it is date sensitive (31 Aug did not display, whereas 3 Aug did) , and possibly to do with localisation of the date (I have date format set to dd/mm/yyyy).

A simple DLL interface that allows an application to test whether dcupdater is installed (say a function to return the version of dcupdater) would allow an application to show relevant menu options only when dcupdater is available.

Owen