ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

DonationCoder.com Software > DcUpdater

LATEST VERSION INFO THREAD - DcUpdater - 1.32.01 - May 9, 2017

<< < (25/26) > >>

IainB:
@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.
________________________
-mouser (April 01, 2017, 03:34 PM)
--- End quote ---
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.    :Thmbsup:
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).    :Thmbsup:

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



cranioscopical:
New version uploaded, recursive update looping should be fixed now.
-mouser (April 02, 2017, 10:08 AM)
--- End quote ---

Working well now.
Can't find anything, anywhere in DCU, that fails to scale appropriately.  :up:

mouser:
Excellent  :Thmbsup:

mouser:
Version 1.32.01 - May 9, 2017

* [BugFix] Fixed error complaining about "-dontofferdcupdaterpage" flag, seen when checking for updates in Screenshot Captor.

IainB:
@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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version