control when updates run and multiple instances of wyupdates

I am using some conditions to ensure that the user is authorized for updates and then I call .ForceCheckForUpdate(true).

1) Is there a way to ensure that the wyupdate.exe will not run right after the new wyDay.Controls.AutomaticUpdater() but only when i call the .ForceCheckForUpdate(true)?I am afraid I have witnessed times that the wyupdate.exe has run by itselft and the updates have downloaded and installed and not triggered by my code.

2)When there is an update, I use the ReadyToBeInstalled event to show an installation button.I see that wyupdate.exe is still running on the background.Then if I run another instance of my application (on another folder), the updates aren't working, it seems like more than one instance of wyupdate.exe is not working.Is this by design? if yes how I can ensure that the wyupdate.exe is closing after checking for updates and executed again only when I call .InstallNow() ?

thanks in advance

Is there a way to ensure that the wyupdate.exe will not run right after the new wyDay.Controls.AutomaticUpdater() but only when i call the .ForceCheckForUpdate(true)?

Yes, set the "UpdateType" property to "DoNothing". Then, before you've checked for updates set the "UpdateType" property to "Automatic"

I am afraid I have witnessed times that the wyupdate.exe has run by itselft and the updates have downloaded and installed and not triggered by my code.

That's by design. By default the AutomaticUpdater automatically updates.

Then if I run another instance of my application (on another folder), the updates aren't working, it seems like more than one instance of wyupdate.exe is not working.

The AutomaticUpdater should work with multiple instances of apps -- I just tested it and it works here. What do you mean by "not working"? I assume all the instances of your app are running from the same EXE, correct? That is, you don't have separate folders for each instance.

Thanks for the replies.

for the multiple instances:

I have two separated folders:dir1/ & dir2/ each with wyUpdate.exe in it.

I execute wyUpdate.exe in dir1. I get the "Latest version already installed" dialog and I don't click "Finish". In taskmanager, wyUpdate.exe process seems running.

Without closing it, I go to dir2. If I try to execute wyUpdate.exe (double click) it does nothing. Nothing opens or appears in taskmanager.

The same seems to happen from my application. When I execute my application that finds an update, the wyUpdate.exe stays open until I close the application. If I try to execute another instance of my application on another folder, then the updates are never checked for availability.

Can you advice me please?

Why are your instances in separate directories? If you run multiple instances from the same executable then everything will work fine.

Are you using multiple apps and this is where the problem happens? Did you copy the wyBuild project files for these separate apps (should shouldn't have -- create them from scratch)? Did you copy the AutomaticUpdater control from one app to the other (if you did do this then you need to change the GUID)?

We have built an application that could be installed as several instances in different folders.Every installed instance has the same copy of wyUpdate.exe, client.wyc & turboactivate.dat, and the same GUID too.I am not sure how we could change the TurboActivate's GUID for each instance as we used one installer that creates the different instances. But then again we want to update from the same wys files, so I assume we want to keep the same GUID as it is the same application, right?

This has nothing to do with TurboActivate. I was talking about the AutomaticUpdater GUID property.

We have built an application that could be installed as several instances in different folders.

Can I ask why you're running multiple copies of the exact same app rather than running multiple instances of the same app? When would this ever be useful?

I think the problem is that using my application, the wyUpdate.exe doesn't close after finding an update.

I am calling .ForceCheckForUpdate(true) and if an update is available, I run some UI stuff in ReadyToBeInstalled event. The wyUpdate.exe is still open. Is this by design?I believe by then wyUpdate.exe should be closed and rerun when I call .InstallNow()

regards

The problem is that you're running multiple copies from multiple directories. Why aren't you just running multiple instances from 1 copy?

Hello again and thanks for your time.The problem is the same even if I try to run the application from the same folder (1 copy, 2 instances)When there are no updates evailable, the wyUpdate.exe terminates and the second instance executes fine.

It there are updates, then wyUpdate.exe stays open until I call the InstallNow().So when I try to execute the second instance it crashes.When I try to debug the second instance it says:"The process cannot access the file 'C:\Users\internet\AppData\Roaming\wyUpdate AU\395fc06c-fa7f-49e1-8ce7-18cf00f387da.autoupdate' because it is being used by another process."

Can you please review the procedure I follow? Maybe I do something wrong and so the wyUpdate.exe doesn't close.

Basically I use this code:

..... here I register some automaticupdater's events ......

automaticUpdater1.wyUpdateCommandline = "-urlargs:\"" + RegistrationPanel.GetPKey + "\"";automaticUpdater1.wyUpdateLocation = "wyUpdate.exe";

automaticUpdater1.UpdateType = wyDay.Controls.UpdateType.OnlyCheck;automaticUpdater1.ForceCheckForUpdate(true);//automaticUpdater1.ProgressChanged += new wyDay.Controls.UpdateProgressChanged(automaticUpdater1_ProgressChanged);

I have checked .Automatic, .OnlyCheck & .CheckAndDownload

Regards

I'll look into this.

Any news on this?regardsIoannis

This is being fixed in the AutomaticUpdater 2.6.15

Great news.Have you planned the release day?regards?

I love deadlines. I like the whooshing sound they make as they fly by.

-- Douglas Adams

We've already set a couple of dates that have come and gone. wyBuild 2.6.15 has a larger scope than most "bugfix" releases, hence the delays. But we're working on it.