deleting files during update

Am I doing anything wrong?

Nope. I apologize this is a bug with the "catch-all update" -- it doesn't remove dead files. We'll fix this either for 2.6.13 or 2.6.14. Thanks for spotting this.

Hi Wyatt,

thanks for your answer.You might have expected that question: is there any release schedule? How far are 2.6.13 (or 2.6.14) away?

If I understand you correctly, I can avoid that hassle if I do not make use of the "catch all" update, correct?I often had the impression, that during update, in most cases the catch all update is used, although the .wyu files that allow an update from version to version are available, too. For me, it seems like your answer further supports my assumption. However, then I'm asking myself: what makes my installer use the catch all update?

A few questions in that regard:* is there any log file (or so) where I can see which files were used during update?* what could be the reason that the catch all update is used?* what happens if I alter older versions (inadvertently)? Can that be the problem?* Wouldn't it make sense to lock previous versions since altering them does not make sense anyway?

Thanks for you answers.WyBuild is a great product, concerning our software updates it makes life much easier for me. However there are still some rough edges where improvement seems possible. (I'm getting off topic, I know)

* version handling: If I'm making a new release, most of my files haven't changed. So what I'm doing is importing a new version via xml file that gives me a new version with all the files in it that were already present in the previous version. This works, but is a bit laborious. I would prefer to have a menu where I could choose the action "clone version" (or so).* Start page: recent version list: it were great if not only the file name of the project would be given, but also the directory where the file resides (maybe via tooltip, the path might be quite long).* naming of versions: for each project, you have general information. The product name of that general information is taken for the header of the tab pane. My problem is that I have different projects with identical product names (for different customers). Now its hard for me to tell apart which tab corresponds to which project file. It would be nice if the name of the project file were included in the header of the tab. Or maybe you can implement a tooltip for each tab that includes the name of the project file. Or any other solution that is a remedy for that.

Thanks for your answers

Best regardsAndreas

You might have expected that question: is there any release schedule? How far are 2.6.13 (or 2.6.14) away?

We're releasing 2.6.13 later today (or early tomorrow). The bug will be fixed in 2.6.14 in a couple of weeks.

If I understand you correctly, I can avoid that hassle if I do not make use of the "catch all" update, correct?

Yes, but the catch-all update was used because the user altered one of your files (i.e. a patch failed).

* is there any log file (or so) where I can see which files were used during update?

No, wyUpdate doesn't make logs (as of v2.6.12). This is high on our priority list, but this is a harder problem to solve than you might expect.

* what could be the reason that the catch all update is used?

Uncheck "Create a catch-all update for corrupt installations" in " File -> Properties -> Update & server files":

[attachment=0]no-catch-all.png[/attachment]

Rebuild & re-upload your updates. Now when the update fails the user will see exactly which file failed to patch.

* what happens if I alter older versions (inadvertently)? Can that be the problem?

Yes.

* Wouldn't it make sense to lock previous versions since altering them does not make sense anyway?

Maybe. We're trying to make version management easier. We've been throwing around a thousand ideas, but the tricky part is making it easy to use for new users and existing users. This is a very hard problem to solve.

version handling: If I'm making a new release, most of my files haven't changed. So what I'm doing is importing a new version via xml file that gives me a new version with all the files in it that were already present in the previous version. This works, but is a bit laborious. I would prefer to have a menu where I could choose the action "clone version" (or so).

If you're following our recommendations as stated in the Step-by-step walkthrough article then you're storing your files in separate folders. So if we add a "clone version" option then you'll have to delete all the old files and re-add them anyway.

But I understand your point -- version management is less than ideal. We're working on it.

* Start page: recent version list: it were great if not only the file name of the project would be given, but also the directory where the file resides (maybe via tooltip, the path might be quite long).* naming of versions: for each project, you have general information. The product name of that general information is taken for the header of the tab pane. My problem is that I have different projects with identical product names (for different customers). Now its hard for me to tell apart which tab corresponds to which project file. It would be nice if the name of the project file were included in the header of the tab. Or maybe you can implement a tooltip for each tab that includes the name of the project file. Or any other solution that is a remedy for that.

Ok -- we'll squeeze these in to an upcoming release.

Hi,

thanks for your detailed anwswer.

<quote>If you're following our recommendations as stated in the Step-by-step walkthrough article then you're storing your files in separate folders. So if we add a "clone version" option then you'll have to delete all the old files and re-add them anyway.</quote>

Yes, I saw your recommendations in the Step-by-step walkthrough article. However, inside my project, I have quite a few versions. Many of those versions do affect few files only. So copying *all* whole files into a new directory would result in unwanted duplication of many identical files. That's my I would like to see a "clone" functionality implemented. I agree that this might not be the way to go in all cases, but in my case, it would definitely make building a new version much easier.One question though. Form my understanding, there is nothing wrong in referencing the same file from different versions, correct? (You will get warnings for each of those files then, but I don't mind). Or could that practice lead to (unwanted) use of the catch-all update for corrupt installations? Just wondering myself if I'm doing anything right.

Thanks for your answer

Best regardsAndreas

One question though. Form my understanding, there is nothing wrong in referencing the same file from different versions, correct? (You will get warnings for each of those files then, but I don't mind). Or could that practice lead to (unwanted) use of the catch-all update for corrupt installations? Just wondering myself if I'm doing anything right.

Nothing bad happens, but this warning solved the #1 frequently asked question: "When I updated my app, nothing changed". That is, people were treating wyBuild as a compression program -- assuming that it would "take care of the files". Now that we have the warning we no longer get that question.

But these warning also explain why sometimes your users get the catch-all update instead of the patch. My guess is you're accidentally copying over an "old" files with a "new" file that you didn't know had changed (maybe a compiler automatically regenerated it). So wyBuild builds the patches from the new "old" file that only you have (your customers have the old "old" file). Does this make sense? This is why we recommend keeping your versions in separate folders and letting wyBuild figure out what's changed.

I know the filesizes can become a problem, but frankly space is cheap -- you can get a 3TB harddrive for $150. If you wait another year the price will drop another $100.

Hi,

meanwhile I found out why the catch-all update is used: previous versions were referencing to files that weren't actually deployed (your assumption why right basically).

I'm encountering a few other problems, though:

a) I did an update where the catch-all-update was used. After the update, files that were removed in the latest version were still present. I used the latest version 2.6.13 for building the update and after the update, wyupdate.exe inside the root application directory was at its latest version 2.6.13, too. For me it seem like the bug reported by me isn't fully fixed yet.

b) I ran into difficulties while applying an update. That's what I did: I created an update and forgot to include a .dll that was newly added. So I added that .dll to my project file, recreated the .wyu + wys files and uploaded them to my server again. I tested the update again, but the .dll was still not present. I decided to test the update on a different machine on a different network and voila.. everything worked like expected. For me it seems like the server files are cached somewhere. I'm inside a company network and we use a proxy-server (ISA-server) to access the internet. I asked our system administrator, and he told me that the proxy does *not* cache any files. So I'm wondering myself if there is any other place (locally on my PC) where those files are cached. I cleared the cache for temporary files of my internet explorer, to no avail. Any ideas on that topic? It's very hard to track down any problems if you are uncertain if you are actually receiving the latest version of your server files.

ThanksAndreas

a) I did an update where the catch-all-update was used. After the update, files that were removed in the latest version were still present. I used the latest version 2.6.13 for building the update and after the update, wyupdate.exe inside the root application directory was at its latest version 2.6.13, too. For me it seem like the bug reported by me isn't fully fixed yet.

Yes, it's coming in wyBuild 2.6.14.

b) ...

To clear the AutomaticUpdater cache then completely empty these two folders:

%userprofile%\wc%appdata%\wyUpdate AU

If the computer is still caching the files then it's a problem somewhere in your internet layers (caching locally, caching on the local intranet, or caching by your ISP).

One additional question, to be on the safe side:

Does wyupdate cache the file "wyserver.wys" anywhere?

Thanks for your reply

Andreas

Yes, inside a subfolder in the "%userprofile%\wc" folder. But if it's not in there it's not stored anywhere else.

a) I did an update where the catch-all-update was used. After the update, files that were removed in the latest version were still present. I used the latest version 2.6.13 for building the update and after the update, wyupdate.exe inside the root application directory was at its latest version 2.6.13, too. For me it seem like the bug reported by me isn't fully fixed yet.

Yes, it's coming in wyBuild 2.6.14

.

There's nothing mentioned about this bug in the release notes of version 2.6.14.Was this issue addressed with the newly released version?

Best regardsAndreas

Sorry, no, we had to delay fixing this for other bug fixes. I apologize -- this fix is coming soon.

Hi,

Quote from a recent post:

> Here's the schedule: we're finishing wyBuild 2.6.15 this week.

Will the issue raised in this thread be fixed in version 2.6.15?

Thanks in advance

Andreas

Hey Andreas,

Yes, this is coming with 2.6.15.