ThinApp User’s Guide : Updating and Linking Applications : Application Updates That the End User Triggers : Application Link Updates

Application Link Updates
The Application Link utility connects dependent applications at runtime. You can package, deploy, and update component pieces separately rather than capture all components in the same package.
ThinApp can link up to 250 packages at a time. Each package can be any size.
The Application Link utility is useful for the following objects:
Large shared libraries and frameworks – Link runtime components, such as .NET, JRE, or ODBC drivers, with dependent applications.
For example, you can link .NET to an application even if the local machine for the application prevents the installation of .NET or already has a different version of .NET.
If you have multiple applications that require .NET, you can save space and make a single .NET package and point the multiple applications to the .NET package. When you update .NET with a security fix, you can update a single package rather than multiple packages.
Add-on components and plug-ins – Package and deploy application-specific components and plug-ins separately from the base application.
For example, you might separate Adobe Flash Player or Adobe Reader from a base Firefox application and link the components.
You can deploy a single Microsoft Office package to all users and deploy individual add-on components for each user.
If you capture Microsoft Office and try to access a PDF attachment in the virtual Microsoft Outlook environment, you can set up Microsoft Office to detect a linked Adobe Reader package on the network when Adobe Reader is not available within the immediate virtual or physical environment.
Hot fixes and service packs – Link updates to an application and roll back to a previous version if users experience significant issues with the new version. You can deploy minor patches to applications as a single file and reduce the need for rollbacks.
The Application Link utility provides bandwidth savings. For example, if you have Microsoft Office 2007 Service Pack 1 and you want to update to Service Pack 2 without Application Link, you would transfer 1.5Gb of data per computer with the deployment of a new Office 2007 Service Pack 2 package. The Application Link utility transfers just the updates and not the whole package to the computers.
View of the Application using Application Link
Figure 4-1 shows the running application with a merged view of the system, the base application, and all linked components. Files, registry keys, services, COM objects, and environment variables from dependency packages are visible to the base application.
Figure 4-1. View of the System, Base Application, and Linked Components Using Application Link
Link a Base Application to the Microsoft .NET Framework
Review this sample workflow to link a base application, MyApp.exe, to a separate package that contains the Microsoft .NET 2.0 Framework. Make sure that the base application capture process does not include the Microsoft .NET 2.0 Framework. For information about the process of capturing an application, see Capturing Applications.
For information about required and optional Application Link parameters and formats in the Package.ini file, refer ThinApp Package.ini Parameters Reference Guide.
Link an application to Microsoft .NET
1
During the capture process, you must select at least one user-accessible entry point.
2
Rename the.exe file that ThinApp produces to a .dat file.
This renaming prevents users from accidentally running the application.
The name of the .dat file you select does not matter because users do not run the file directly. For example, use dotnet.dat.
3
Save the .NET project to C:\Captures\dotnet.
4
5
Save the project to C:\Captures\MyApp.
6
Open the Package.ini file in the captured application folder for the base application.
7
Enable the RequiredAppLinks parameter for the base application by adding the following line after the [BuildOptions] entry.
RequiredAppLinks=dotnet.dat
Application Link parameters must reference the primary data container of the application you want to link to. You cannot reference shortcut .exe files because these files do not contain any applications, files, or registry keys.
8
a
Double-click the build.bat file in C:\Captures\MyApp.
b
Double-click the build.bat file in C:\Captures\dotnet.
Running these batch files builds separate ThinApp packages.
9
a
Copy C:\Captures\MyApp\bin\MyApp.exe to \\<end_user_desktop>\<Program_Files_share>\MyApp\MyApp.exe.
b
Copy C:\Captures\dotnet\bin\cmd.exe to \\<end_user_desktop>\<Program_Files_share>\MyApp\dotnet.dat.
Set Up Nested Links with Application Link
ThinApp supports nested links with the Application Link utility. For example, if Microsoft Office links to a service pack, and the service pack links to a hot fix, ThinApp supports all these dependencies.
This procedure refers to AppA, which requires AppB; and AppB, which requires AppC. Assume the following folder layout for the procedure:
For information about setting up required and optional Application Link parameters in this procedure, refer ThinApp Package.ini Parameters Reference Guide.
Set up nested links
1
2
In the Package.ini file, specify Application B as a required or optional application link.
For example, add RequiredLinks=\AppFolder\AppB\AppB.exe to the file.
3
4
In the Package.ini file for Application B, specify Application C as a required or optional application link.
For example, add RequiredLinks=\AppFolder\AppC\AppC.exe to the file.
5
If you start Application A, it can access the files and registry keys of Application B and Application B can access the files and registry keys of Application C.
Affecting Isolation Modes with Application Link
ThinApp loads an Application Link layer during application startup and merges registry entries and file system directories. If ThinApp finds a registry subkey or file system directory that did not previously exist in the main package or layer that is already merged, ThinApp uses the isolation mode specified in the layer being loaded. If the registry subkey or file system directory exists in the main package and a layer that is already merged, ThinApp uses the most restrictive isolation mode specified in any of the layers or main package. The order of most restrictive to least restrictive isolation modes is Full, WriteCopy, and Merged.
PermittedGroups Effect on Linked Packages
If you link two applications and you specify a value for the PermittedGroups parameter, the user account used for starting the application must be a member of at least one of the Active Directory groups for this parameter in the Package.ini files of both applications. For information about the PermittedGroups parameter, refer ThinApp Package.ini Parameters Reference Guide.
Sandbox Changes for Standalone and Linked Packages
Sandbox changes from linked packages are not visible to the base executable file. For example, you can install Acrobat Reader as a standalone virtual package and as a linked package to the base Firefox application. When you start Acrobat Reader as a standalone application by running the virtual package and you change the preferences, ThinApp stores the changes in the sandbox for Acrobat Reader. When you start Firefox, Firefox cannot detect those changes because Firefox has its own sandbox. Opening a .pdf file with Firefox does not reflect the preference changes that exist in the standalone Acrobat Reader application.
Import Order for Linked Packages
ThinApp imports linked applications according to the order of applications in the RequiredAppLinks or OptionalAppLinks parameter. If either parameter specifies a wildcard character that triggers the import of more than one file, alphabetical order determines which package is imported first.
The OptionalAppLinks parameter might appear as OptionalAppLinks=a.exe;b.exe;plugins\*.exe.
Using a.exe and b.exe as sample executable files, ThinApp imports linked packages in the order described in Table 4-1.
 
Table 4-1. Imported Linked Packages  
Import Order
For information about nested links, see Set Up Nested Links with Application Link.
File and Registry Collisions in Linked Packages
If the base application and a dependent package linked to the base application contain file or registry entries at the same location, a collision occurs. When this happens, the order of import operations determines which package has priority. The last package imported has priority in such cases and the file or registry contents from that package are visible to the running applications.
VBScript Collisions in Linked Packages
VBScript name collisions might prevent scripts in other imported packages from running. If you link packages with Application Link and those packages have scripts with the same name, ThinApp places the VBScripts from the linked packages into a single pool. For scripts with the same name, ThinApp runs the script from the last imported package and disregards the other scripts.
For example, a base package might contain the a.vbs and b.vbs files and a dependent package might contain the b.vbs and c.vbs files. Because a filename collision exists between the b.vbs files, the VBScript in the last imported package specified in a RequiredAppLinks or OptionalAppLinks parameter overrides any previously imported scripts with the same name. In this case, ThinApp condenses the pool of four .vbs files into a single pool with the a.vbs file from the base package and b.vbs and c.vbs files from the dependent package.
VBScript Function Order in Linked Packages
In a pool of VBScripts for packages linked with Application Link, functions in the main bodies of the scripts run in alphabetical order of the script names. ThinApp callback functions in the scripts run in reverse alphabetical order of the script names in the pool.
Storing Multiple Versions of a Linked Application in the Same Directory
If the directory holds a linked package, and you add an updated version of the linked package in the same directory, the Application Link utility detects and uses the updated version.
Using Application Sync for a Base Application and Linked Packages
If you use Application Link to link packages to a base package, and you start the base package, Application Sync can update only the base package. For example, if you build a Microsoft Office 2007 package with Application Sync entries in the Package.ini file, build an Adobe Reader package with Application Sync entries in the Package.ini file, use Application Link to link the two packages, and start Microsoft Office 2007, Application Sync only updates Microsoft Office 2007. You can update both Microsoft Office 2007 and Adobe Reader by starting each application separately.
If you do not update all the applications and link a base application to an expired plug-in, the base application can still load and use the plug-in.