Running 1 file more than once

Hey Jim,

Are you asking how to execute the same exe twice? If so, you can do that using a batch file. That is, create a batch file that executes your app twice.

Hi Sam,

This is a batch file I would like to run before and after the update for the purposes of starting (and backing up the server directory temporarily) and stopping a server application. I added parameters to pass a switch to determine when to start and stop it as well as the "%basedir%" variable path.

While creating a new release we have an option to call upon that batch file once using the radio buttons "before updating has begun" or "after updating is complete". However, I don't see a way to call it once before the update and once after the update. There is a "Update Actions" section which only allows interactions to windows services, but alas, I'm not in that boat for this project.

I hope that this clarifies it.

Thank you for your time.

Jim

You can't call the same batch file twice (that's just a limitation we put in). You can, however, create another batch file that launches whatever other batch/exe files and have that run whenever you want it to.

Does that make sense?

I know, but this is what I wanted to avoid. The actions are really best kept in 1 file to manage especially if the parameters are exactly the same. I may have another way, but I see these as workarounds rather than solutions when getting into updates with more conditions.

Thank you again for your time.

Jim

Well, I guess the bigger question is, why are you having the batch files backup your app? wyUpdate does this by default. If that is all your batch files are doing, then they're unnecessary.

Sam,

I'm glad you brought up the backup detail, but I mentioned before this was to start and stop a server process as well. The backup was being done outside of wyUpdate because I ran into an issue where the update failed after the files were already updated and wyUpdate didn't roll it back the application files. I tried to read up on how this backup solution (Or rollback rather) worked, but didn't see a detailed explanation. What I noticed through testing was the last version referenced in wyUpdate was rolled back to allow the user to pull down updates again. Unfortunately, if we run into a situation where our build media has an issue we couldn't catch in testing this could create critical issues. I am new to your product so perhaps, you could explain how this backup solution works. I see where you are creating a temporary folder, but didn't see any of the actual application files being backed up.

Perhaps, I should mention what I'm currently assigned to do. We have several server side product that we need to streamline in pushing out our updates to our customers. One of the server products is an application which also provides client updates in a subdirectory. We need to be able to supply new updates from a cloud server, currently we plan to use your product to retrieve the media, and cleanly update the server files/directories.

I have been thinking about this and I can accomplish the same thing by using the batch file to only stop the server process and then configure your updater to automatically start the server up afterwards. I guess this resolves my original issue, but there certainly may be other instances where I would need to call a utility application to run more than 1 task (e.g. Before and After the update). If that is the case, I wouldn't want to create multiple copies of this same application in order to satisfy the design of wyBuild. To me that sounds more like a limitation.

Jim

I see where you are creating a temporary folder, but didn't see any of the actual application files being backed up.

Any file that will be patched or deleted by wyUpdate is first backed up into a separate folder. If the update fails to patch then the "new" files are removed and the old files are put back where they belong.

If you make changes outside of wyUpdate's system (let say you have a batch file that deletes all your files and you execute that as part of your update) then wyUpdate won't know about the changes to the files and thus not back anything up or restore the files on a failed update.

but there certainly may be other instances where I would need to call a utility application to run more than 1 task (e.g. Before and After the update). If that is the case, I wouldn't want to create multiple copies of this same application in order to satisfy the design of wyBuild. To me that sounds more like a limitation.

This is a limitation, for sure, but you're the first person to mention it. Maybe we'll let wyBuild execute a single file both before and after update in a later version.

I'm probably mentioning it because I'm new at using your product. I appreciate your patience (and honesty) while I'm understanding best practices for your product. I've actually found that I do not need to even use the batch file since you already do a check if a certain process is running and shut it down.

I guess I'm so used to building things myself that I missed your default functionality. 😀

However, I just ran through my test to start up a process after the update is complete, but the process never starts. I don't see any CPU change or the process showing up in Task manager. I do have a commandline parameter which I included (There is also a shortcut on the desktop which has the same thing and starts fine). My original elevation configuration in the "Files & Folders" was set to same as wyUpdate, but also tested with Elevated and still didn't start. I can see that the files are being updated, but not sure what I'm doing wrong here. Your config section is very straight forward.

Thank you,

Jim

However, I just ran through my test to start up a process after the update is complete, but the process never starts.

Did you rebuild the updates and re-upload them to your server?

Yes and perhaps this was the issue. I have rechecked and the configuration to start up the server process was still set to run after the update. This only occurred twice, and haven't been able to replicate this.

I think at this point we can call this one closed.

Thank you,

Jim