Thinstall allows you to upgrade or roll-back an application version
which it is still running. The upgrade process will occur
automatically when the user quits the application and runs it a
second time. In terminal server environments, you can have multiple
users executing different versions at the same time during the
transition period. The process for doing in-place upgrades or
roll-backs is very simple and is described below.
Locked files
While applications are running, the EXE package will be locked and
it cannot be replaced, deleted, or moved. This file lock ensures
that any computer or user accessing a specific version of an
application will continue to have that version available as long as
their application process and subprocesses are running.
If an application is hosted in a central location and run by many
users, this file lock means you cannot replace a packaged EXE with
a new version until all users have released their locks on the
file. This is not always easy to accomplish without using
Thinstall.
Upgrade Mechanism Thinstall has an upgrade mechanism
that allows you to deploy application upgrades even while older
version are still in use by users. This mechanism is as simple as
copying the new version into the old deployment directory with a
.1, .2, .3, ... filename extension.
Example:
1. Deploy Version 1.0 of myapp.exe Copy
application to central share at \\server\share\myapp.exe(c:\program
files\myapp\myapp.exe is also another typical location)
Push a desktop / start menu shortcut to user's desktop which points
to shared EXE location at \\server\share\myapp.exe
2. After some time 2 users (user1 and user2) have launched
myapp.exe and continue to use it
3. Now, you'd like to deploy Version 2.0 of myapp.exe, but you
can't because the file is locked by 2 users. The solution:
Copy Version 2.0 of myapp.exe to central share at
\\server\share\myapp.1
After
step 3, anytime a new user executes \\server\share\myapp.exe it
will automatically relaunch using the package data in myapp.1
In this fashion, users' shortcuts do not need to be updated; when
you upgrade an application, the shortcuts continue to point to
myapp.exe
If user1 and user2 quit the original version 1.0 of myapp.exe and
reexecute it, they will start using version 2.0.
You can deploy version 3.0 of my app by placing it in the same
directory with a higher number at the end.
Copy Version 2.0 of myapp.exe to central share at
\\server\share\myapp.2
Once myapp.1 becomes unlocked you can delete it but myapp.exe
should remain in place since the user shortcuts continue to point
here. Thinstall will always use the filename which has the highest
version number, so if you need to accomplish a roll-back to an
earlier version and the most recent version is still locked, you
need to copy the old version so it has the highest version
number.
Sandbox considerations
When you release an upgrade to an application, you can control
whether the user continues to use his or her old settings by
keeping the sandbox name consistent in your package.ini file. By
deploying a new application version with a new sandbox name, each
user will create a separate sandbox and start with a fresh install
maintaining isolated settings. If you deploy with the same sandbox
name, users will keep their old settings.
Special Note: Security Implications Because apps can be
upgraded by dropping in a new file in the same directory as the
main application, the directory (and not just the file) where an
application is hosted should be read-only for normal users.
Downloading upgrades Note: If you are a software
developer and want to download new versions of your application
from the Internet, you should store the temporary download files in
a separate filename/directory until the download completes. Once
the download has finished you can use an atomic MoveFile operation
to move the file from the temporary location to the application's
directory so that the next time the application restarts it will
use the newer version. You must use an atomic operation because
applications using MoveFile in the virtual environment may have
sandboxing / WriteCopy applied.