Feature request: Offline install solely from all.to.XXX.wyu

Some of our applications using wyUpdate are deployed on computers without internet access. The -updatepath and -server arguments to wyUpdate are giving me trouble when all I want to do is update exclusively from the appname.all.to.newestversion.wyu file.

I have a folder containing appname.all.to.2.14.2.wyu and wyserver.wys. When I start wyUpdate as

wyUpdate.exe -updatepath=file://C:/temp/wyupdate-test/ -server=file://C:/temp/wyupdate-test/wyserver.wys

then it does see that there is a change available and it does show the details (suggesting it correctly read the wyu file, although possibly it is reading from the cache). However, then it tries to load appname.2.13.to.2.14.2.wyu from the FTP server contained in the client.wyc file, and it fails immediately because it cannot resolve the FTP server. It should fall back to the "all" update named in the updatepath folder instead of dying completely at that point.

Rather than going through all of this hassle, I would prefer to just have a new option along the lines of

wyUpdate.exe -forceupdate=file://C:/temp/wyupdate-test/appname.all.to.2.14.2.wyu

that would make a best-effort attempt to update from that file alone without looking for server.wys anywhere.

My intent with the offline update is to build a small program that will store my wyu file somewhere on disk, launch wyUpdate against that file, and then remove the update file. For this application, offline updates will be fairly common, so the less I have to do, the better.

Doing offline updates seems to be a popular feature request. We'll try to bump up the release of standalone patch creation.

Let me ask you this: are you specifying the "%updatepath%" variable in your site list (e.g. %updatepath%/%file% )? Because that's the value that wyUpdate replaces when you use the "-updatepath" commandline switch.

that would make a best-effort attempt to update from that file alone without looking for server.wys anywhere.

The server file contains necessary information (i.e. the signed hash of the updates, the minimum required version of wyUpdate, etc.).

It's kind of annoying to actually go through an offline update since I have to unplug my network cable to fully simulate an offline update... but here's my most in-depth description of the steps I take:

I have the following versions of this particular application: 2.13, 2.13.1, 2.14, 2.14.1, and 2.14.2. I copy the whole 2.13 folder into a new directory so that I don't overwrite the "gold" version.

The download sites that I have in wyBuild are "%updatepath%/%file%" and "ftp://user:pass@ftp.mysite.com/%file%". For all the versions listed, the %updatepath% one was listed as both a server and update site (it was not obvious that I had to right-click to set it as update-only, but future versions will include that).

So I open a command prompt and cd to the 2.13 folder. First, I run:

C:\temp\wyupdate-test\2.13>wyUpdate.exe -updatepath=file://c:/temp/wyupdate-test/ -server=file://c:/temp/wyupdate-test/wyserver.wys

Where C:/temp/wyupdate-test contains the 2.13 folder, app.all.to.2.14.2.wyu and wyserver.wys.

And I get the error: Error trying to save file: Error downloading "http://wyday.com/files/wyupdate/updates/client.wys": The remote name could not be resolved: 'wyday.com'

That error is fine, because I didn't copy over the wyUpdate.exe from 2.14.2. So I copy that over and run the same command as before.

wyUpdate tells me that the current version is 2.13 and the latest version is 2.14.2, so I click "Update" to start the update, but then I get the following error: Error trying to save file: Error downloading "ftp://user:pass@ftp.mysite.com/app.2.13.to.2.14.2.wyu": The remote name could not be resolved: 'ftp.mysite.com'

If I copy just app.2.13.to.2.14.2.wyu into the C;/temp/wyupdate-test folder, and run the same command, then I am able to successfully and fully update. However, the problem is that I cannot be sure of which version that a customer is running. I could copy all the individual updates (2.13, 2.13.1, etc.), but even then, I would need the catch-all update in case a file on the customer's computer was corrupted. So instead of just including a 6MB catch-all update, I'm forced to include a 6MB catch-all plus 5 more updates at ~300KB each.

Even if I specifically corrupt the folder (deleting a single DLL, for instance), wyUpdate attempts to download 2.13.to.2.14.2.wyu, presumably because it cannot know that the set is incomplete until it fails to update with 2.13.to.2.14.2.

I'm still fine with rolling my own offline update utility for my specific circumstance (in the meantime before wyUpdate-offline), but hopefully this demonstrates the problem with how I have to include every possible wyu file when I should only have to include one (the catch-all).

It's kind of annoying to actually go through an offline update since I have to unplug my network cable to fully simulate an offline update... but here's my most in-depth description of the steps I take:

You're exactly right. %updatepath% was a hack to begin with - and the hassle you have to go through confirms this. We'll try to push up standalone patches (a.k.a. an executable that patches your app without needing an internet connection) up to wyBuild 2.7.

wyUpdate tells me that the current version is 2.13 and the latest version is 2.14.2, so I click "Update" to start the update, but then I get the following error: Error trying to save file: Error downloading "ftp://user:pass@ftp.mysite.com/app.2.13.to.2.14.2.wyu": The remote name could not be resolved: 'ftp.mysite.com'

Well you can skip this particular error by not including 2 sites in your wyBuild project. Just include the "%updatepath%/%file%" site and specify the ftp site using the "-updatepath" commandline switch.

Even if I specifically corrupt the folder (deleting a single DLL, for instance), wyUpdate attempts to download 2.13.to.2.14.2.wyu, presumably because it cannot know that the set is incomplete until it fails to update with 2.13.to.2.14.2.

That's right - wyUpdate presumes the file exists on your "server" (even if "server" means local disk) and it presumes that the user hasn't touched any files he shouldn't have touched. Only after patching has failed does wyUpdate know that the installation has been screwed with by the user.

Unfortunately there's no easy way to make the offline patch hack that is "updatepath" to work more sanely. Which is why we're re-prioritizing proper offline patching.

Reply
Discard post