By default, two virtualized applications are isolated from each other. Application One cannot see files or registry entries virtualized in Application Two's package. The ThinApp feature AppLink lets packagers allow full integration between two or more packages. AppLinking packages will effectively merge the different virtualized environments into one big environment. ThinApp supports up to 250 packages linked together but in reality you will never AppLink that many packages together.
There will be a penalty in the startup time for each AppLink and pretty soon your implementation will become too complicated to maintain and manage. Try to limit the amount of AppLinks between five to ten.
AppLink will allow you to package your main application into one package and any dependencies as AppLink. This allows for a more modular design of your desktop environment. A typical use case is a packaged browser and Java, .NET, Active X, Flash as AppLink packages. AppLink is not limited to dependencies. A packaged Microsoft Office and an application tightly integrating with Office can be AppLinked together. This way it will look like both the applications are locally installed on the client, and full integration between applications is possible.
The package your end users launch first is called the parent package. Any AppLink packages are referred to as child packages. There is no difference between a parent and child package. Both are valid, normal ThinApp packages. A package being a child when Application A is launched can just as easily be a parent when you launch it separately. Adobe Acrobat Reader is an excellent example. It can be launched as a separate application but is often a child to your packaged Internet Explorer.
Let's say you packaged Internet Explorer and Adobe Acrobat Reader in two different packages. If you associate .pdf files to your Acrobat Reader Package you will be able to click on a link to a .pdf file from within your virtualized Internet Explorer and a separate Acrobat Reader window will be used to display the Acrobat document. If you want Internet Explorer (IE) to use the embedded Acrobat Reader within the IE window you must AppLink the two packages together. This way Internet Explorer will see Adobe Acrobat Reader as locally installed. The registry keys identifying the embedded functionality in IE will be present in the virtual environment.
When you launch a parent package, its virtual environment will load first, and then the child packages' environments will be merged into the active environment. This happens every time you launch the parent package. If you change the content of a child package the new updated environment will be merged upon the next launch of the parent package. This allows individual updates of your packages. The load order is either alphabetic or in the order specified within Package.ini.
The following is an example of an alphabetic load order:
[BuildOptions] OptionalAppLinks=C:\Plugins\*.exe
The following is an example of a predefined load order:
[BuildOptions] OptionalAppLinks=C:\Plugins\LoadMeFirst.exe; C:\Plugins\LoadMeLast.exe
When you configure AppLink, it is important to understand that you have to point to a data container. It is the virtual environment stored in the data container you want to merge into your running environment. So if your AppLink package uses a separate data container, make sure you refer to the correct file extension, that is, FileName.dat.
ThinApp supports one parent package being AppLinked to up to 250 child packages. ThinApp also supports many parent packages AppLinking to one child package. A child package can have its own AppLink, and nested loading of AppLinks is fully supported. This means you could end up launching one parent package, AppLinking to one child package that loads one or more child packages of its own. Pretty soon you risk losing the complete overview of where files and registries are located and which isolation mode is active. A file or a registry key may exist in more than one package in your AppLink chain. In order to resolve these conflicts, the ThinApp runtime will use "last loaded". This means if you have C:\Temp\File.txt in your parent package and in your child package, the version in your child package will be used. Parent environments are always loaded first and then child environments are loaded in either alphabetic order or in the load order specified within your Package.ini file. What about isolation modes? Here the ThinApp runtime uses a different method, wherein the most restrictive mode will win. This means if your parent package has Merged on the folder C:\Temp, then make sure not to use any other isolation modes in any of your child packages. Remember that nested packages will be part of the whole AppLink chain as well. Now it's getting clearer why I recommend using only a small number of AppLink packages in a desktop environment design.
An AppLink package is only loaded once per execution. If you have a complex AppLink chain referring to the same child package multiple times, the child package will be merged only once, the first time it is referred to.
WriteCopy versus Merged, WriteCopy will win
WriteCopy versus Full, Full will win
AppLink will discard any sandboxes existing for the child package. Let's say you AppLink to Adobe Acrobat Reader. This package might have been used separately and therefore has the user settings stored within its sandbox. Now, when you execute the parent package, the parent sandbox is the only one in use and any settings stored within the Adobe Acrobat's sandbox will not be part of the running environment.
If your child packages have any virtualized services or VBScripts, they will be active when using AppLink. Bear in mind that, starting services may be a time consuming task. AppLinking to a package starting services might therefore add extra time to the launch time.
ThinApp supports the following two flavors of AppLink:
Optional AppLink
Required AppLink.
When using the dynamic
AppLink called OptionalAppLinks in Package.ini, the package will AppLink to any package available. If no AppLink can be found, the package will happily launch anyway.
Using Optional AppLink offers a true dynamic design of your applications. You don't even have to know upon packaging if you need to AppLink or not. Simply activate OptionalAppLinks and you can always add functionality to your package later on.
The following are example configurations:
[BuildOptions] OptionalAppLinks=plugins\*.exe
The result of this configuration is that, any package located in the folder called plugins relative to the parent package itself will be added.
[BuildOptions] OptionalAppLinks=plugins\*.exe; plugins\*.dat
The result of this configuration is that, any package located in the plugins folder relative to the parent package will be AppLinked, including separate data containers.
[BuildOptions] OptionalAppLinks=\\ServerName\ShareName\MyAppLinks\Java.dat
The result of this configuration is that the Java package located on a network share will be AppLinked.
[BuildOptions] OptionalAppLinks=C:\Program Files\Java 1.6 (VMware ThinApp)\*.exe; C:\Program Files\Flash (VMware ThinApp)\*.exe
The result of this configuration is that, if available, a virtualized Java and locally deployed Flash clients will be AppLinked. This is a very common AppLink configuration used when you deploy ThinApps with the help of MSI and existing deployment tools. We will get back to some different deployment scenarios later.
[BuildOptions] OptionalAppLinks=%HOMEPATH%\*\*.exe
This configuration shows that, AppLink supports environment variables and wildcard searches. This example will search one folder deep in the users %HOMEPATH% for child packages called *.exe.
[BuildOptions] OptionalAppLinks=\\ServerName\ShareName\*\*\*.dat
In this configuration, ThinApp will search two folders deep for child packages named *.dat. For example, both \\ServerName\ShareName\AppLinks\Java\java.dat and \\ServerName\ShareName\AppLinks\Flash\Flash.dat will be AppLinked.
Required
AppLink, called RequiredAppLinks in Package.ini, will deny execution of the package if the AppLink cannot be found. When you use a required AppLink, make sure you specify the whole filename of your child packages. You should not use the wildcard (*) since this will effectively disable the required rule set, that is, deny usage of the parent package if AppLink packages are not available.
[BuildOptions] RequiredAppLinks=C:\Program Files\Java 1.6 (VMware ThinApp)\java.exe; C:\Program Files\Flash (VMware ThinApp)\flash.exe
This configuration means that the Java and Flash packages will be AppLinked. If they are not accessible, the user will be denied the ability to run the parent package.
[BuildOptions] RequiredAppLinks=\\ServerName\ShareName\java.exe
This configuration means that the Java package located on a network share will be AppLinked. If the Java package is not accessible, the user will be denied the ability to run the parent package.