Launch App after update

Hey Dan,

The way to do this is have something else execute wyUpdate (e.g. your app). If wyUpdate says there's a new update then launch wyUpdate and exit your app. Also, tell wyUpdate to re-start your app if something goes wrong. And inside your update make sure you execute your app after a successful update.

Hmm, I see this is not what i was hoping the user flow would. This is what i was hoping for:

- user launches wyupdate.exe which check for updates- if there are updates it loads the updates and then launches myapp.exe and if no updates launches myapp.exe

for some reason this flow is only working if myapp.exe was one of the files that was updated. Am I missing something here or is this basic workflow simply not possibly using wybuild and wyupdate?

Thanks,Dan

Am I missing something here or is this basic workflow simply not possibly using wybuild and wyupdate?

No, but the alternative works. It just flips the order of things (your app is called, then wyUpdate).

I have been trying to make this work as per your suggestion but having some unexpected behaviour:This is some of my code: Process foo = new Process(); foo.StartInfo.FileName = "wyUpdate.exe"; foo.StartInfo.Arguments = "/quickcheck /justcheck /noerr"; foo.Start(); foo.WaitForExit();

Then my next code is: if (foo.ExitCode == 2) { Process fo = new Process(); fo.StartInfo.FileName = "wyUpdate.exe"; fo.StartInfo.Arguments = "/skipinfo"; fo.Start(); Application.Quit(); }

Is this what I should be using? So the unexpected behaviour seems that the "waitforexit" can take a long time, up to several minutes, secondly I am not sure if my Application.Quit() call should be placed at the beginning of my second call or at the end (where it is sitting right now in the above sample).

Any code someone can share that works well. Trying to keep this as seemless as possible.

Thanks,Dan

That code looks good. The reason the checking might be slow is that you're blocking the self-update site. Double click the client.wyc file to see all the sites that will be accessed when checking for update. If any one of those sites is blocked then the update checking will be slow.

Ok so far so good. The basic update flow as described above seems to be working however a small problem but serious one.

One of the items in the update is the main app executable, so this file can change. Right now the flow is as follows:1) launch app2) check for updates, if exist the user can opt to exit the app and we do a commandline wyupdate)3) update is finished and we load the main executable as an excute file after update has completed.

So this works but the main executable loads data that resides inside the program files folder but it seems the the executed file as the post update is not reading from this directory e.g. is it launched from this? If I close the app and load the app again via the program menu it works fine, it is the newly updated app version AND it loads the data.

Hope i am explaining this clear enough, any help anyone can offer?

Thanks,Dan

I'm not quite sure what you're saying. Everything is executed correctly, right? But the problem is that your app loads data and it's not being loaded correctly under certain circumstances? Is that the gist of the question?

Have you tried attaching a debugger to your app? It's likely because you're loading data relative to the "current directory" of the app, and the "current directory" is a relative thing.

Yes,

the app is loading data from the same directory as the exe is launched from. So my guess is the wyupdate does a temp-directory thing? Now i can start looking at a batch file that does some smarts around program files and load the exe from there but that is never bullet proof.

So when i put my main exe inside the wybuild and mark it as "execute file after update" where is this file execute from because it looks like it is not the my programs folder? Is it using a temp and then after the update is finished it copies it over? A little surprised at the seen behaviour.

Thanks,Dan

Ok, I solved this problem had to do with the new Windows & virtualstore concept. By making the post update exe to run NOT elevated it fixed the problem. Basically what was happening was that there was the administrator run exe (post update command) and the normal user run exe and one was writing inside program files and the normal user was writing inside virtual store.

Dan