In <a href="http://blogs.egroup.jasonmangone.com/?p=1225">Part One</a> of the VMWare ThinApp AppLink Series we talked about how to package dependant packages in a seperate package than the main virtualized application using VMWare's ThinApp.  In Part Two we will continue with that process by explaining how to tie all thos packages together and discussing the benefits of seperating your packages.<!--more-->

When thinking about the benefits of being able to package dependant applications seperatley from their parent applications there are a few things that jump right out at you.
<ol>
	<li>Single Source for Upgrades and Patches:  Continuing with the .Net Framework example, being able to have a single package that can be updated and immediatly and seamlessly be pulled by all of your virtualized applications is a huge timesaver.  This means that you only have to apply that security patch to one package and all the applications linked to it start using the latest version.  You can get around compatibility issues with upgrades and packages by maintaining a version history of the packages in your file share and associating the correct package version with the application.</li>
	<li>Reducing the storage footprint:  In virtualized application environments, packaging and linking applications reduces the redundancy of code and functionality across all of your packages.  In addition to reason 1, this reduces the amount of storage required for your virtualized application environment.</li>
</ol>
Now that we have made a case for creating multiple packages and linking them together using AppLink.  This is how it is done.  We will start with the VM that we just installed and "ThinApped" the .Net Framework on from Part 1.  No need to revert to the pristing snapshot since .Net will be a dependancy of our parent application.
<ol>
	<li>Restart the VMWare ThinApp Capture Tool.</li>
	<li>Gather the Pre-Install Snapshot</li>
	<li>Install the parent Application normally.</li>
	<li>Gather the Post-Install Snapshot.</li>
	<li>Enter your Isolation Mode, Capture Folder, MSI options and create the application capture folder.</li>
	<li>Browse to the application package folder and open the package.ini file using notepad.</li>
</ol>
The Pacakge.ini file contains many configuration options for your application that you should get familiar with.  The ones we are looking for at the moment are OptionalAppLinks and RequiredAppLinks.  OptionalAppLinks is just about what it claims to be, these are application packages that are optional and if cannot be found or unable to load they will be ignored by the parent app.  RequiredAppLinks are the opposite.  If these pacakges cannot be loaded then the application will not continue to load.  Use the RequiredAppLinks for dependancies required for the parent application to run.  Easy enough, right?

We start by removing the comment (semi-colon) from the beginning of the RequiredAppLinks line since .Net is a requirement for our package to execute normally.  There are many ways in which you can reference a package.  Here are a few examples...
<ul>
	<li>Relative Path: ..foldernameappname.exe</li>
	<li>UNC Path: <a href="//\servernamesharenameappname.exe">\servernamesharenameappname.exe</a>.  Remember to set up a file share with appropriate access permissions for the UNC path to utilize as the admin shares (c$, etc...) can cause permissions issues.</li>
	<li>Local Path: e:path.  You can enable a new "Virtual Drive" below by copying the default link "VirtualDrives=Drive=C..." if you want to add another disk location such as an e: drive or a cdrom.  The only thing required is the Drive= so you need not worry about the serial number or the type.  Fixed is default.  Also see the examples in the package.ini for removable disks.</li>
	<li>Plugins folder with wildcard:  Create a plugins folder in the bin folder of the captured application and copy all of your dependany executables into it.  You can reference them individually or by using a wildcard. plugins*.exe.  Remember, this way requires you to have multiple copies for dependant applications.</li>
</ul>
After the package.ini is configured, save it and select "Build Now".  You now have a package that references dependant packages.  I recommend putting some thought into the storage structure of your packages before building them so that you can maintain organization and standards for your virtualized applications file share.