No issues, just technical questions...

After updating a console application, it needs to run afterwards. The thing is, we'd like to use a head update but the console app requires dynamic arguments to be passed. We are trying to avoid having too much logic... ie; dumping the arguments into a file, updating and then checking for the existence of said file to get the previous arguments. I see there is a /startonerra argument but that only works when an error occurs. Is there a argument, maybe I overlooked, that will pass arguments to the executed file after a successful update? I do see where I can add static arguments in wyBuilder.

No, you have to specify the file as part of your update.

Leads me to my next question, if an update fails and gets rolled back, will it still be executed if the checkbox is checked on wyBuild, to run the file after the update? I don't want it to get into an infinite loop of failed updates.

When an update rolls back as a result of any wyUpdate failure (fail patching, etc.) then no file is executed. If you checked the "rollback on failure" option for one of your executables then obviously that executable will be run (and any executables that preceded it).

Is there a way to force old files to be removed. Example, delete an old .dll or config file that isn't being used anymore.

Yes. Let wyBuild handle it. Namely, follow the step-by-step walkthrough. Include all your files for every version. If wyBuild sees OLDVERSION has a file but NEWVERSION doesn't have that file, then wyBuild is smart enough to know that the file has to be deleted when wyUpdate updates your app.

Is there a way to NOT update a file if it has been modified without excluding it completely from the updater? Example, a config file that has user specific data.

Exclude the file from all versions.

I know I seen it somewhere but in the past hour of reading through the help, I can't find where it mentions roll backs and how to set them up. Can you link to it please?

wyUpdate handles rollbacks automatically if there's a failure in the update. You don't have to do anything special.

Thanks for the response, Sam. I see a minor technical issue and hopefully it can be resolved in a future release or is there a way around it now?

For example, you introduce a new config file in an update. The next update, you don't want to overwrite the current config file so you exclude it from the update. WyUpdate will then delete that file because it isn't included in the update.

For example, you introduce a new config file in an update. The next update, you don't want to overwrite the current config file so you exclude it from the update. WyUpdate will then delete that file because it isn't included in the update.

Well, like I said in my previous post, the way to avoid this problem is to remove the config file from within wyBuild. When wyBuild doesn't know a file exists then it won't do anything to it.

I was talking about introducing a new config file after the initial release. Example... You roll out your program, 20 updates later you want to add a config file to save the user settings. The next update, that config file will be overwritten if it is included in the update and deleted if it isn't included.

Your app should create the "template config". If you don't want to do that, then simply include the "template config" in the temporary folder in wyBuild and create a batch file to execute and conditionally copy the config file.'

But really this should be done in your app.