We have an internal desktop application which we have deployed to a network share. In that directory are subdirectories for each version, ie, z:\Apps\ApplicationX\1.0 z:\Apps\ApplicationX\2.0 z:\Apps\ApplicationX\2.1
I would like to put a shortcut on the user desktops which point to the newest version of the application. My current solution is to put the current version into a directory called "z:\Apps\ApplicationX\Current", and put a shortcut on their desktop to the exe there.
The problem is that when they are running the application, I can't update the application because the file is locked.
I tried changing the shortcut to point to a batch file which copies the file locally and then runs it from there, but we're all on Windows 7, and UAC is causing issues copying the file to the C: drive where I would expect it to be installed.
I suppose I could copy the executable to the users home drive and run it from there, but I don't like the idea of having an executable in the users home drive. It also means that there are multiple copies of the application on the network, which I'm not a fan of.
I also thought that I might be able to have a shortcut to a shortcut and I would just update the shortcut, but that doesn't work either.
My current solution is to have a batch file which has the start command in it pointing to the current version, and a shortcut to that batch file.
Does anyone else have possible solutions?
Sounds like a legacy application. Your best bet is going to be to not over complicate it, and just schedule downtime for updates.
My preferred method, two applications. The main app you already have. The second is a launcher/updater. Make a shortcut to the launcher, it checks a config setting (encrypted gibberish, xml, plain text, hard-coded directly into the launcher, whatever) for the path of the executable to launch then launches it. Once the main app is launched, the loader will terminate.
Whenever you get a new version, you update the config file of the launcher and future program launches will then open the new version.
It is the "boot loader" style process. Have a tiny assistance app that points to the full sized app. Clients launch the tiny app and it then directs them to the proper full app.
Bonus points if you have your launcher check hash fingerprints or signatures on the full sized apps to ensure no one gets creative and tries to link to another app from the launcher.
I agree with DanBig that in your simple situation unless you want to revamp it a lot (like Ruscal suggests, which is a good idea) just schedule an "outage" where you kick the file lock(s) and replace the .exe file (maybe overnight or on a weekend).
As far as getting them on the desktop, why not have your shortcut point to z:\Apps\ApplicationX\ and place the current EXE there. Then have subfolders for past revisions/versions as necessary like z:\Apps\ApplicationX\revisions. This way the client shortcut never changes, and during updates you simply move the existing exe into a rev# folder and place the new/updated .exe into the z:\Apps\ApplicationX\ folder.
I agree with DanBig and TheCleaner. We have an internal app like that. The shortcut goes to
\\server\share\application\application.exe, and when we need to do updates, I wait until the users go home for the day, and use Server Manager or Computer manager to close the open files so new ones can be copied.It's not pretty, but anything else is uglier, IMHO.
You can use a Samba server running on a Linux. When you need to update the application, just rename the "current" folder and create a new one with the name "current". The share must be read-only.
On Linux (Unix) renaming or deleting a file is allowed and processes that have the files opened will be able to use the old version until the file descriptor is closed.