Upgrading Applications
Previous  Top  Next

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.


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.