just means i uploaded a slightly newer version of farr without updating the file on the website saying the new version is available.

A short while back, I got an update notice for dcupdater - I downloaded and installed USING dcupdater - I still get the message, saying I need to upgrade from 1.26.01 to 1.28.01 - but when I do Help - About, it says I am running 1.28.02! I just did a new download and install - same version situation.

The dcupdatersetup.exe that I downloaded is 2,121,728 bytes. dcupdater.exe is 3,004,416, and does show an internal version # of 1.28.2.0, modified on 10/10/10 at 7:15PM.

Did I get a bad version somehow?

Thanks
Dan

you dont have a bad version, just me being a bit sloppy with version numbers.  however i think if you re-install the new update it should say you have version 1.28.01 and stop offering an update (even though you really have 1.28.02).  it shouldnt say you have 1.26.01 if you get new version.

Still no luck. I tried a fresh download and install. Same thing. So I un-installed dcupdater, renamed:
C:\Users\Dan\AppData\Roaming\DonationCoder\DcUpdater
to
C:\Users\Dan\AppData\Roaming\DonationCoder\DcUpdater-old
and
C:\Program Files\DcUpdater
to
C:\Program Files\DcUpdater-old
then did another fresh download (to a different name) and install - STILL got the same thing! It says installed version 1.26.01, version on the web 1.28.01. Help - About says I am running 1.28.02. As does looking at the Program Properties - Details.

There is a directory
C:\Users\Dan\AppData\Roaming\DonationCoder\Keys
which I did not rename ...

Any directories or registry keys I should clean up?

Sorry about this, and thanks for your help.
Dan

Thanks for the update, mouser. What do you mean with not zip-compatible?

No posts in this forum since July 2013. I thought I'd change that by saying I just tried out DCUpdater by using it to install some new software and it appears to work flawlessly. Nothing has updated yet, though. We shall see.

It even detected my FARR plugins. 

Thanks for the info, tomos!

A cool feature would be a toggle in the options to treat beta releases as regular updates. 

Would make it a little easier for those who want to help test.

Wow.

I thought this was officially abandoned. Even SC seemingly stopped using it.

1) During installation DCU gave me something along the lines of "the following process needs to be closed..." but no mention of what that process is.
2) After a brief dance with this I uninstalled the updater.
3) Installed again and was informed that there are no valid update packages.
4) Had DCU system notifications in a font so huge that only a word or two would fit.

Will I have better luck on April 2nd?
Baffled on Baffin Island. 

Notification fint foxed 

DCU can't find CH+S despite having just installed it.

A whole lotta loopin' goin' on (see image)

@mouser: Where you say:

My apps should all still use it if it's installed, but I have definitely stopped "promoting" it, as I essentially gave all my apps the ability to CHECK for updates using code built into them (DcUpdater will download and run the installler).
So anyway, DcUpdater is not really needed anymore, and it does seem a bit overkill.
________________________

I appreciate what you say there, but I'm a fan of DCUpdater's, because it saves me some time/trouble.
I have long preferred to use DCUpdater to auto-manage updates (i.e., check for new version, download, install) for all DC apps., all in a single operation, rather than get each app to update itself on an ad hoc basis using DCUpdater. I regularly launch DCUpdater from a FARR button, and it does any update checks/installs in one fell swoop.
This necessitated a bit of careful organisation, initially, of the two files:

• [Name of app].dcupdate
• [Name of app].dcupdateredirect (contains the explicit path to the app. folder)

- but, once done, it's a breeze.   
By organisation, I mean there is a copy of both of the above files in each DC app. folder, and a copy of every [Name of app].dcupdateredirect in:
  C:\ProgramData\DonationCoder\DcUpdater\RedirectFiles

I keep all the apps. (including DCUpdater) in folders within a Plugins subfolder to FARR:
  C:\UTIL\Windows utilities\FindAndRunRobot\Plugins\

All the apps. have ConfigDir.ini files set with:

• PORTABLE=TRUE
• CONFIGDIR = .

- which all seems to work OK (most of the time).   

DCUpdater thus outputs useful/helpful/informative reports like this, when it runs, and it's very fast:   

Excellent 

@mouser: I've manually worked around this minor problem for ages, but running DCU (DCUpdater) on itself today, reminded me to ask you: Is there any way that the user can force DCU to always adhere to using the app folder path that is set in the .dcupdateredirect file for each of the apps?
DCU seems to somehow temporarily get its knickers in a twist when it runs and updates itself or another app, and I have not so far been able to figure out what is going on.
After doing an update, DCU seems to "see" only the apps that have been updated, and does not seem to "see" the other apps. - I think it expects to see them in the default program files folder, but doesn't find them there, and yet it can "see" those that it has just updated.
Otherwise, it runs very smoothly as per my post above.

I have FARR installed in a path C:\UTIL\Windows utilities\FindAndRunRobot\ and I have all my other DC apps (including DCUpdater) that I am using on a regular basis, or trialling, in subfolders in a path C:\UTIL\Windows utilities\FindAndRunRobot\Plugins\
I put that path and the app folder into the .dcupdateredirect file for each of the apps - e.g. in the DCUpdater app folder, the path in the .dcupdateredirect file is:
  C:\UTIL\Windows utilities\FindAndRunRobot\Plugins\DcUpdater
- and so on for each of the other apps.

That's how I get the very useful output (app listing) from DCUpdater that I posted about, above, and is how I keep track of any updates to the DC apps that I am using.
When I ran DCUpdater (from a button in the FARR app) today, it detected and updated the two apps that had been just updated by you - DCU and SC (DCUpdater and ScreenshotCaptor) - but when I re-ran it (again from the FARR button) it could only "see" (list) those two updated apps.
Restarting FARR seems to fix the confusion, and after running DCU from the button I have for it in FARR, DCU worked fine again.

It may be that (say), somewhere in the update app process, the default path (programs folder) is being temporarily set in a variable somewhere, and somehow overrides the path(s) set in the .dcupdateredirect file(s) or causes those files not to be opened. Thus, restarting FARR and DCU seems to clear everything and fixes it.