Multiple exe instances with the same AutoUpdater.GUID

When wyUpdate is in "AutomaticUpdater mode" it functions as a server that takes requests from the AutomaticUpdater instances. It processes requests in the order it receives them, and tells all AutomaticUpdater instances about its current progress.

So, what is the recommended way to update multiple instances ? When upgrade processes do not overlap, everything is fine. Problems arise when they overlap, which can be a not so uncommon scenario.

Here are some of the pb I've faced.

[Reproductible] When instance1 has started the update process - e.g. UpdateStepOn in (UpdateAvailable, ReadyToBeInstalled) -, a call to InstallNow() in instance2 will end up in DownloadingOrExtractingFailed with the ErrorMessage "wyUpdate ended before the current update step could be completed."Should I test this string to understand the situation and show proper information to the user ("Another instance is currently being upgraded.....")? Not very clean...

[Not reproductible on demand] In approaching scenarios, the error can sometimes look like "Cannot patch file <some file>". But it won't make it to DownloadingOrExtractingFailed as it's then eaten in pipeClient_MessageReceived (cf my other post) and the user just don't know what is going on.

Sometimes Instance1 gets affected in turn. Sometimes not.

Most of the time, closing one instance or the other, fixes the situation more or less beautifully. By "less", I've encountered situations where the download step would run twice (with success) and other oddities I don't remember.

NB : Each of my instances is deployed with its own set of wyUpdate.exe and wyClient.wyc files.

NB : Each of my instances is deployed with its own set of wyUpdate.exe and wyClient.wyc files.

This is the problem. Why are your instances using separate wyUpdate.exe and client.wyc files?

We support multiple instances through the same installation setup executed with different destination directories. Each installation is consequently agnostic of the other.

With this deployment design, I don't see how instances could share the same wyUpdater.exe file. All the more since you told me it should preferably be left in the same directory as the application itself.

Another possibility would be to let users run multiple instances of the same exe file. We don't because of the way our app is currently designed.

This will cause problems -- in fact it's probably the cause of all your problems. Since your app instances aren't running from the same exe, you must use a different GUID value for each separate install location. The problem is the GUID has to be set at design time.

Why don't all of you instances run from the same installation location? This would save you a lot of hassle, a lot of bandwidth, and (depending on the size of your app) a lot of hard disk space on your users computer.

Thanks for your help Sam,

95% of our users stay away from multi-instances because we discourage them.

In contrary to what I wrote, when they do, this is most of the time by executing the same exe twice. Although it "works", we discourage this practice because our design does not deal very well with shared data (User settings, user cache, etc...). This is also the reason why I thought about orienting them towards multi-instance through separate installations, until we improve our design or purely forbid multi-instance at all. I agree this is not the best way to do multi-instances.

For the moment, very few users have the possibility to deploy multiple installations of the app to have multiple instances running. This ability is used in the following scenarios:- Testers. Side by side deployment of our production and test versions. Different setups and versions but same GUID. Having to maintain seperate GUIDs for Prod and dev is an option we would like to avoid.- Testers/Developers/Support. To exceptionnally test separate versions of the application side by side.- Testers/Support. To reproduce a user's environment without impacting their main installation.

The problems I mentionned in my initial post have only been faced by myself. That confirms your assumption.

But all of the other problems reported so far in other threads concern users having only one installation of our app. This goes agains your assumption.That said, looking back, a fair proportion of the problems are faced on machines where multiple-instances of the same exe are run. We will test this scenario further.

Still, as we need it to some extent, is there a way to support multiple instances through several exe files? If I understand correctly I'd kind of need to define the GUID dynamically at runtime before the AutomaticUpdater gets initialized. But it's currently not possible.

Still, as we need it to some extent, is there a way to support multiple instances through several exe files?

No, but you could make your app have multiple instances using the same exe. That would work fine -- in fact wyUpdate & the AutomaticUpdater was designed from the ground up to handle this case.

We will improve our design in the future. But that is gonna be some work plus it will not cover the scenarios I described.

I'm thinking to modify the automatic updater this way:- Add an OnInitializingGUID event to give my app a chance to provide its own GUID.- In the handler, I would try to read the GUID in some local file.- If the file does not exists, I would generate both the file and the GUID.

Do you see any problem with that?What would be the best place to trigger the event.

Do you see any problem with that?

Yes, there are problems with that. The GUID is used in the ISupportInitialize.EndInit() function. That is, the GUID will be used before any event is triggered.

The best (and frankly, easiest) solution is to do one of 2 things:

1. Make your app single instance and don't allow multiple installs.
2. Or, allow your app to have multiple instances and don't allow multiple installs.

Hello Sam,

Again, I agree doing multi-instance through a single exe rather than several installations is the cleanest way to go in most scenarios. And I appreciate the fact that the AutomaticUpdate can deal with that. But,1 - although we will change our design, this is gonna take some effort and time,2 - still the support/debug scenarios I mentionned can only be covered by multiple installations.

Therefore, I'm still trying to find a solution to multiple installations upgrades.

You said that different GUIDs would be one way to support multiple wyUpdate installations working isolated. So I explored that route a bit (purposely ignoring the "GUID must be set at design time" limitation as it's probably easy to build a unique string from the application location and pass it to the AutoUpdaterInfo constructor).

I built two separate applications with different GUIDs and custom built wyUpdater.exe/client.wyc files. It seems that even so the updates are not isolated:- If application A is running and already initiated an update process (UpdateStepOn <> Nothing) with its wyUpdate instance, application B will get an error ("wyUpdate ended before the current update step could be completed.") in return of any attempt to call its own wyUpdate instance.- If I close application A, then B can proceed with the update. But if it happens to download an update, the latter will replace in the wc cache any update pending for A. So A downloaded an update for nothing.

So, to my understanding, the current design mostly expects kind of serialized updates system wide.- One single wyUpdate, sytem wide, exe can be talked to at a time.- UpdateInfo are kept isolated for each application GUID in \wyUpdate AU but not the \wc cache.- Therefore, once an application has downloaded an update, it'd better complete the installation before another application starts its own update process and throws away what has just been downloaded.

Of course, if one keeps upgrade cycles short and/or have only one wyUpdate enabled application deployed, this may not be a problem.

Am I making sense?Can you consider making updates isolated per wyUpdate installations?

Thanks.

- One single wyUpdate, sytem wide, exe can be talked to at a time.

This is not true. Multiple instances of wyUpdate can run at a time and work fabulously.

- UpdateInfo are kept isolated for each application GUID in \wyUpdate AU but not the \wc cache.

This is not true. When you build wyUpdate with a separate wyBuild project then it generates a different GUID that's used in the "\wyUpdate AU" folder. The GUID used in the \wc folder is set in the AutomaticUpdater -- this is the same problem we were talking about earlier.

Can you consider making updates isolated per wyUpdate installations?

They already are isolated for 99.99% of the use-cases. Frankly, this is the first time I've heard of installing multiple instances of an app to multiple locations. For instance, if a user wants to run 2 instances of Microsoft Word they don't have to install Microsoft Office twice -- they just need to run the app twice.

I recommend you use wyUpdate as a silent updater (instead of the AutomaticUpdater control) until your fix your app to run multiple instances from the same location.

Sam wrote:>

- UpdateInfo are kept isolated for each application GUID in \wyUpdate AU but> not the \wc cache.

> > This is not true. When you build wyUpdate with a separate wyBuild project then it> generates a different GUID that's used in the "\wyUpdate AU" folder. The GUID used> in the \wc folder is set in the AutomaticUpdater -- this is the same problem we> were talking about earlier.

Damned. I did use separate wyBuild projects. But one of which was a tweaked copy of the other (to save me the pain of redefining in full each and every project properties). Indeed, with a new project created from scratch, applications A & B update isolated beautifully.

You might want to add a note about the danger of copying a wyBuild project to start a new one.BTW, is there a way to renew the GUID of an existing wyBuild project?

>

Can you consider making updates isolated per wyUpdate installations?

> > They already are isolated for 99.99% of the use-cases. Frankly, this is the first> time I've heard of installing multiple instances of an app to multiple locations.

There is always a first time

> For instance, if a user wants to run 2 instances of Microsoft Word they don't have> to install Microsoft Office twice -- this just need to run the app twice.

Different beasts really. Word is a schrink-wrapped software. I'm in charge of our in-house production system. It calls specific testing / support / deployment needs.If you read me, it's not just about my end-users running multi-instances of the exact same executable. Testers and Support staff also need 1 - the ability to run side by side the "production" and "test" installations of our client software.2 - the ability to run side by side different minor versions of our "production" environment.

Those users are not IT, having them dealing with virtual machines is not an option.

Anyway, thanks to this thread I made good progress.To deal with -1-, I will amend my build process so that the "Test" client embeds a different AutomaticUpdate.GUID than the "Production" client. I will also make sure that their respective wyBuild projects do not share the same "wc" GUID.For -2- (which is less important than -1-), I might just ensure myself that one instance updates at a time.

> I recommend you use wyUpdate> as a silent updater (instead of the AutomaticUpdater control) until your fix> your app to run multiple instances from the same location.

I will explore that route, but I'm not sure this will give the level of control I need on the update process. Remember my post "Caching all available updates but mastering their install." . Yes, again, I'm having uncommon needs.

Thanks again for your help.