I had a glitch in the initial release our of our software, that had the download folder specified incorrectly:
In Service Pack 1 of this release, I corrected the wyp file to specify the location correctly:
Now, for the sake of the current install base, I uploaded the .wys files to get from initial release -> SP1 into the "wrong" folder-path. I was able to test that this worked beautifully. If an install of initial release goes to look for an update, it finds it at the wrong location on the server, and then downloads the update needed for SP1.
Where it gets weird:
At this point, I would expect that the installation of their software - which has been updated to SP 1, would look at the correct server path (since it should now be using the updated .wyc file post update to SP 1. BUT IT DOESN'T. It seems to continue to look at the bad-path, despite otherwise appearing to be correctly updated.
And the opposite is true:
If I install a fresh copy of SP 1 (which has the correct .wyc file), the try to do "check for updates", I'm told "error, server not found". Well, at this moment that's correct (they .wys file is not at the correct location, but at the bad-path, so this error is correct - I'll upload another copy of the .wys to this location shortly).
But you see: the two upgrade paths lead to different outcomes: if you upgrade from the original through wyUpdate, it *still looks in wrong path*, but if you upgrade through our software (i.e. install from our CD of SP1), then it *looks in correct path*.
Huh?!
What am I missing?
The "client.wyc" file contains references to your *.wys file(s). The *.wys file contains references to your *.wyu files.
If I were to guess I would say you didn't rebuild wyUpdate and include the latest client.wyc in both your latest updates (i.e. within wyBuild) and with your latest installer. Also make sure you've updated your FTP or SFTP upload sites to upload to the correct location.
Tell me if this helps.
How would we include the not-yet-generated .wyc file to be used by wybuild? It creates that file... seems like chicken & egg issue?
Initially, there is C:\builds\1.0.wyp has 1.0 tab (nothing else).Running wybuild creates wyUpdate.exe and client.wyc.I copy client.wyc and wyUpdate into c:\builds\1.0 for distribution as part of our installer.
Later, there is C:\builds\1.1.wyp now has 1.0 and 1.1 tabs.Running wybuild creates wyUpdate.exe and a new client.wyc.I copy client.wyc and wyUpdate into c:\builds\1.1 for distribution as part of our installer.
However, at the point in time where I run wybuild, I only have none or an old client.wyc for it to see (i.e. initially there isn't one in c:\builds\1.0, and later, there isn't one in c:\builds\1.1, but is an older one in c:\builds\1.0).
How would I run wybuild in order to get the .wyc file, and then feed it back into 1.1 in order to include that new version of that file in the generated .wys?
Seems like wybuild should automatically be doing this on my behalf, as I'm no sure how it's physically possible for me to do it (doesn't exist at the point in time wybuild is creating the end product that needs it).
:confused: 😉
Seems like wybuild should automatically be doing this on my behalf, [...]
Yes, it should. We would squeeze this into wyBuild 2.6.15 but we've already delayed the release a number of times due to "feature creep". We're shooting for 2.7 release for this feature. But you're right, this is confusing if you don't know the internals of wyUpdate.
How would we include the not-yet-generated .wyc file to be used by wybuild? It creates that file... seems like chicken & egg issue?
It seems like a chicken & egg issue, but it's not. This is our fault for making this confusing. To include the latest client.wyc with your latest update do it in this order:
Does this help clarify things?
Thanks- it does.
I'm not entirely sure how I would use that from the command line? Currently I only run wyBuild from the build script once, so it sounds like we'll need to run it twice: once to generate the wyUpdate & client.wyc, a second time to generate the .wys+.wyu files.
Alternately, I can just live with my mistake (placing the path at the wrong location initially), and I can just keep the .wys at both the initial "incorrect" location and a second copy at the correct location (which will mean only needing to run wybuild from our script once / cycle).
Thanks for the clarification.
One thing you can further clarify for me: is it possible to alter an existing tab using the -add .xml syntax, or would I need to regenerate that tab twice from the previous version of the .wyp file + two different versions of the -add .xml files (one without, and one with, the needed client.wyc)?
I'm not entirely sure how I would use that from the command line? Currently I only run wyBuild from the build script once, so it sounds like we'll need to run it twice: once to generate the wyUpdate & client.wyc, a second time to generate the .wys+.wyu files.
You can take advantage of one of the features of wyBuild. Namely, when you include a client.wyc file in your updates (that is, in a version tab in wyBuild) then the version number embedded in the client.wyc file is ignored. That is, all the resources are kept (the theme, the download sites, the languages, etc., etc.) but the version number is ignored.
So, what does that mean? It means you can build your new client.wyc once manually for inclusion in your updates. Then include this once client.wyc file in all your new version.
You should still build wyUpdate with every new version and include the newest client.wyc and wyUpdate.exe with your installer. However, for your updates you can use that client.wyc that just has the latest resources (but not the latest version).
I know this can be a bit confusing. Does this make sense?
One thing you can further clarify for me: is it possible to alter an existing tab using the -add .xml syntax, or would I need to regenerate that tab twice from the previous version of the .wyp file + two different versions of the -add .xml files (one without, and one with, the needed client.wyc)?
Are you asking about adding files to an existing version? You can either do it manually or, using the commandline, use the "<AddVersion overwrite="true">" element.
It sounds like everything's been straightened out -- or at least clarified -- here, but I went through a similar situation in the post at https://wyday.com/forum/t/400/bug-not-falling-back-on-multiple-download-sites/ if anyone is interested on another (similar) point of view in experiencing this problem.
