5.1

ThinApp User’s Guide
62 VMware, Inc.
Dynamic Updates Without Administrator Rights
You can update applications dynamically without requiring administrator rights. For example, .NET-based
applications that download new DLL files from the Internet as part of their update process must run the
ngen.exe file to generate native image assemblies for startup performance. In typical circumstances, the
ngen.exe file writes to HKLM and C:\WINDOWS, both of which are only accessible with administrator accounts.
With ThinApp, the ngen.exe file can install native image assemblies on guest user accounts but stores changes
in a user-specific directory.
You can update the package on a central computer and push the changes to client machines or to central
network shares as a new captured executable file. Use one of the following options for applying updates:
 During the setup capture process.
 Inside the virtual environment.
Applications with auto-update capabilities can undergo updates. If the update is a patch.exe file, the
patch program can run in the virtual environment and run from a cmd.exe file entry point. Changes occur
in the sandbox during automatic updates or manual updates to allow you to revert to the original version
by deleting the sandbox.
If you apply patches in the virtual environment on a central packaging machine, you can use the
sbmerge.exe utility to merge sandbox changes made by the update with the application. See
“Application Updates That the Administrator Triggers” on page 58.
 In the captured project.
If you must update a small set of files or registry keys, replace the files in the captured project.
This approach is useful for software developers who integrate ThinApp builds with their workflow.
Upgrading Running Applications on a Network Share
ThinApp allows you to upgrade or roll back an application that is running on a network share for multiple
users. The upgrade process occurs when the user quits the application and starts it a second time. In Terminal
Server environments, you can have multiple users executing different versions at the same time during the
transition period.
File Locks
Starting an application locks the executable file package. You cannot replace, delete, or move the application.
This file lock ensures that any computer or user who accesses a specific version of an application continues to
have that version available as long as the application processes and subprocesses are running.
If you store an application in a central location for many users, this file lock prevents administrators from
replacing a packaged executable file with a new version until all users exit the application and release their
locks.
Upgrade a Running Application
You can copy a new version of an application into an existing deployment directory with a higher filename
extension, such as .1 or .2. This procedure uses Firefox as a sample application.
You do not have to update shortcuts, only the primary data container.
Upgrade a running application
1 Deploy the original version of the application, such as Firefox.exe.
2 Copy the application to a central share at \\<server>\<share>\Firefox.exe.
A sample location is C:\Program Files\Firefox\Firefox.exe.