patching error

Also just to confirm, I definitely haven't modified that file after running my initial installation...

Yes, but this is a settings file that, presumably, your end-user modified. The way you can avoid this file altogether is to remove this "settings.xml" from wyBuild (in all version) this way wyBuild will ignore it when creating patches.

Does that make sense?

No, I am not sure what you mean. In this case, settings.xml is logically read-only - i.e. permanent application settings, nothing user-configurable.

I am the end user just now because I haven't rolled this out yet. I just started over today. I built an installer, and then added the source files to a new wyp project, then ran a new build and built an incremental update via the command line. As part of this incremental update, there is a new exe and a new settings.xml. Then when I run the installed application to try and get the update, I get this error.

Ok, I see. Then the problem is that the version of "setting.xml" that was installed with your installer doesn't match what is in the wyBuild version tab. So make sure you use the correct file in every version in wyBuild.

Tell me if that helps.

It should be the same version, unless I am misunderstanding what you mean.

Here is an overview of the steps involved (starting with an empty (i.e. version 1.0.0, and no files) wyp project:

1. Copy build files to c:\temp2. Generate settings.xml in c:\temp\data\config3. Run wybuild.cmd.exe with /add and /bwu flag4. Copy wyUpdate.exe to c:\temp5. Create Nullsoft Installer and upload/install to a test machine6. Copy c:\temp to c:\temp\updates\1.0.0.07. Build new exe8. Copy changes to c:\temp (using Robocopy)9. Regenerate new settings.xml10. Copy c:\temp to c:\temp\updates\1.0.0.111. Run wyupdate and upload wyserver.wys and update files12. This error when launching the application

Is it because step 9 changes the settings.xml file in the original source directory for the first version? I will try it out with building the installer from c:\temp\updates\1.0.0.0 and see if that makes a difference. I will let you know if it fixes it.

Is it because step 9 changes the settings.xml file in the original source directory for the first version?

Yes, that's very likely. The version of settings.xml in your wyBuild project file must match exactly to the version you include in your installer and that will be distributed to your customers.

I'm afraid that doesn't solve the problem for me. The files are now the exact same - is it saying that there is 186 bytes difference between the files? It would be useful to confirm which file (original or updated) is is saying is too small, or report what total size it is expecting. I will continue to try and work out what the problem is but at the moment I am a bit stumped. It seems like a catch-all update is a potential workaround but I'd rather get to the root of this problem. Is there any way I can force it to continue, and replace settings.xml if present(in the update) or continue past this error?

Did you rebuild your updates and reupload them to your server after you fixed the error? Did you also rebuild your installer with the correct settings.xml file?

I have finally fixed it - I just trashed everything and started over, and to be honest I am not 100% sure what fixed it in the end because I spent hours doing iterative changes to try and work out what was going on. Definitely something to do with the order of tasks in my script. I did come across this error once too:

"Internal error: Exception of type 'System.Exception' was thrown." (otherwise the same as the original error - minus the 186 bytes part). Again this is a file that is recompiled as part of the update process, but I just thought I would post it in case you felt the need to improve the error message in a future build (but I have solved this too; same root cause as my original issue).

Speed of iteration here was pretty slow, it would be really useful if we could get either a way to remove updates from the .wyp file (as you or Wyatt mentioned to me before, we don't want to remove updates because that may leave users with unsupported versions, but in this case such a feature would have been a huge tmesaver for me). If we can't get this, then the ability to "replace" via the command line, rather than just "add" would have helped me too (because adding the same version from xml just gives an error if that build already exists, but doesn't seem to add any new files that are present). Failing that the ability to just create a new .wyp file from scratch via the command line would have done the same job for me.

Thanks for the help 🙂