Multiple instances of same application

If you're using the AutomaticUpdater then there's no easy way to separate multiple instances (stored in separate folders) of an app. This is by design. Of course you can always modify the behavior of the AutomaticUpdater to not check for updates when you're running on an instance copy.

wyUpdate as a standalone updater is easier to do situations like you described.

Thanks Sam.

If I'm correct in understanding this, the problem is that the cache folder is the same for all instances of wyBuild on a machine, and the only difference in them is the GUID. So for two instances with the same GUID, there would be a conflict.

Would it be possible for you to (allow the developer to) move the cache folder to a sub folder of the install location? This would prevent such conflicts.

The reason why I can't use the standalone updater is that the control specifies update server locations, and update file locations dynamically.

Hi

No reply on this in a while... Another user had the same problem with my app - which led me to revisit this post.

Also, this would help in certain other situations. Would it be possible to add the feature to specify a commandline switch to change the Cache folder location? This would be really useful to me.

Thanks

Omaer

Of course, this wouldn't be needed in 2.6.15 - in a future release perhaps...

I can't really see the purpose of specifying a separate cache folder other than for cases where you have a user installing the same app to 2 separate locations:

C:\Program Files\YourAppC:\Program Files\YourApp Copy

And I can't see the practical purspose for doing that. Ideally your installer should detect that behavior and uninstall the first YourApp copy before installing to the "YourApp Copy" folder.

wyUpdate & the AutomaticUpdater already supports multiple instances of your application, however all instances must run from the same location.

Can you explain why you would need the exact same binaries installed to 2 separate locations on the same computer?

Well, there are two usage cases that I can think of.

------------------------------------------------------------------------------------- 1. Have two copies of the same App on the same machine.-------------------------------------------------------------------------------------The first is what I described above - that a user might want two separate copies of my application on his machine. This may be because the two applications are configured differently, running different profiles, or that the user wants to test every update to make sure it runs without problems, and so he keeps another copy installed at a different location for 'roll-back' purposes.

This is the way we are doing things in my company. An example:We have two copies of the application installed at two locations:Copy 1 at C:\Program Files\Test AppCopy 2 at C:\Program Files\Main App

Now, when I push an update, the user can first run the test app to make sure there are no problems, bugs etc - and once he/she is sure of that, then he/she can run the Main App - this prevents roll backs and is an enterprise requirement for me.

------------------------------------------------------------------------------------- 2. Have two or more Apps using the same Updater-------------------------------------------------------------------------------------The second usage scenario is a little unusual. There are a lot of applications used internally in my company. Most of these applications are not developed by me, but I have to keep them up to date for the Middle East and Africa region. The developers of the applications are at various locations around the world, and there is a lot of legacy code so it is difficult to implement wyUpdate directly into the Apps.

What I have done is to develop a single App which uses wyUpdate, and reads the following information from an INI file:1. Application Name2. SQL Server Name/IP3. Name of EXE to execute

Now, my 'Updater' queries the SQL server and dynamically gets the location of the .WYU file and the .WYS file based on it's own COMPUTER Name and the Application Name. It passes this information on to WYUpdate.exe as commandline switches.

Instead of having shortcuts pointing to the applications themselves, I have pointed all the shortcuts to my application instead. Now, when a user runs App1, my updater gets launched instead. It checks for updates, and if it finds some, then it updates the app. If it doesn't find updates, it launches App1.exe instead.

Other than just launching App1.exe, it updates a table in SQL server with the Computer Name, Application Name, Latest Update Version and Any Update Errors, and The file version of the Exe file.

The same can be done with App2, App3 etc by simply modifying the INI file.

This way, I have a single Generic Updater for all the applications that I have not developed, and which need to be updated for the computers for which I am responsible. And this way, I can get feedback on which computer is at which version of which app at the moment. This is working perfectly for my needs.

The only problem is that some computers have multiple different applications running on them - so even though in theory, my generic Updater should work for all the Apps, it can not - because of the Cache file conflict.

To solve this, every time I make any change to the Updater, I recompile it several times, with different GUIDs - one for each of the Apps that it needs to update.

---------------------------------------------------

I know the second usage case is a rare/extreme one, but it is quite useful - and the only downside is having multiple re-compilations of my Updater every time I need to update it.

Hi Sam, any update?

We've been thinking about this -- we're still undecided. Muliple instances can be done currently with separate client.wyc files. But with the AutomaticUpdater things get complicated fast.

Well, I'll admit that the second scenario above would not apply to most of your users. However, I do feel that it should be fairly common to have multiple installs of the same application on a single PC.

One way of doing it could be to use a combination of the Automatic Updater GUID as well as the Automatic Updater File Path to generate the path for the cache files. So instead of storing the cache files in {GUID}, they could be stored in {GUID}\C\Program Files\Test App. The path would be the same one that the Automatic Updater uses to determine the location of WYUpdate.exe

Would this be difficult to implement? Or are there factors other than the Cache Folder Location that would be causing the conflict?

Would this be difficult to implement?

Yes. There are a lot of subtleties that need to be handled.

So instead of storing the cache files in {GUID}, they could be stored in {GUID}\C\Program Files\Test App. The path would be the same one that the Automatic Updater uses to determine the location of WYUpdate.exe

The problem if this is the path limit in Windows. The maximum path is 260 characters. If we waste a lot of these on the temporary folder then that leaves less for the actual company to use for their own filenames.

It gets complicated.

We're still thinking about the best way to handle something like this.

Hi Sam

The problem if this is the path limit in Windows. The maximum path is 260 characters. If we waste a lot of these on the temporary folder then that leaves less for the actual company to use for their own filenames.

Yes that's true... I didn't think of the path name limit.

Well, here's another idea (just throwing it in there since you guys are brainstorming anyway)...In the temp {GUID} folder, you could have an xml file which contains the path of the automatic updater dll and a corresponding cache file location. (Example: <installations> <InstallInstance> <auPath>C:\Program Files\Test App</auPath> <cachePath>...\{GUID}\1</cachePath> </InstallInstance> <InstallInstance> <auPath>C:\Program Files\Main App</auPath> <cachePath>...\{GUID}\2</cachePath> </InstallInstance> </installations>). If a new instance of WyUpdate or the AutomaticUpdater control runs, it would add itself to this file.This file can be used by any instance of wyUpdate to determine what the cache folder location is... And it eats up only another few characters in the folder path.

Another possibility is that you allow the developer to override the cache file location with a command line switch.

Don't worry about it too much though - I'm fine with the multiple recompiles - I hardly make changes to my updater. However, I do feel that it could be a common scenario that the same application is installed at multiple locations - in which case this would need to be addressed.

Regards