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.
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.
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.
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.
|
2
|
Rename the.exe file that ThinApp produces to a .dat file.
|
The name of the .dat file you select does not matter because users do not run the file directly. For example, use
dotnet.dat.
|
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.
|
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.
|
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.
|
|
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.
|
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.
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.
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, see
Configuring Permissions.
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.
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.
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 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 script.
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.
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.
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.
