AppSync - best practices for using Entry Point vs. separate .DAT

[ScottPart]

My company just started using ThinApp. And the four of us responsible for virtualizing have each branched out and taken different training, conferences, read different info, and talked to different experts. When we came together to develop a single process to virtualize applications we have run into conflicting information regarding the best approach for building the Primary Data Container to best utilize the AppSync feature when pulling updates from a servers using a UNC path.

Some experts say they only use the “Use one of the Entry Points” option and others say that if we are going to use AppSync the “Use separate .DAT file” option must be used. We have Googled the topic visited the VMware forums and haven’t found a satisfactory answer to help us choose the correct method. So we figured we would post this question and see if anyone can provide us with the information we need.

What we are trying to figure out is exactly how the AppSync pointer in the program.ini file will react if we use the two options.

For example: Let’s say we virtualize a program called XYZ and the .EXE to run the program is called “xyz.1.0.exe”. We create an .MSI to install the virtual XYZ using SCCM to all of our PCs. We use the location \\Servername\XYZ\ as the AppSyncULR path for the primary data container for future updates. Later XYZ is updated to version 1.1 and after install it the .EXE is called “xyz.1.1.exe”. Rather than push this update using SCCM we want to leverage ThinApp AppSync to automatically update all the PCs to the new version. So we virtualize xyz 1.1 and copy the primary data container to the \\Servername\XYZ\ folder. In this situation what would be the best method to build our Primary Data Container to assure AppSync would update the old virtual XYZ 1.0 on all our PCs to the newer XYZ 1.1 virtual version.

1. “Use one of the Entry Points” which forces us to name our Primary Data Container after the .EXE file “xyz.1.0.exe”. Then setup our program.ini with “AppsyncURL=file://servername/XYZ/xyz.1.0.exe “.When we copy the new Primary Data Container called “xyz.1.1.exe” to the //servername/XYZ folder, will the AppSynceURL in xyz.1.0.exe see the new “xyz.1.1.exe” data container and update xyz.1.0.exe even though we specified “AppsyncURL=file://servername/XYZ/xyz.1.0.exe “ in original xyz.1.0 virtual project?
   
2. “Use separate .DAT file” which allows us to name the Primary Data Container with a generic version agnostic name like “xyz.dat”. Then setup our program.ini with “AppsyncURL=file://servername/XYZ/xyz.dat“. Knowing that we have the ability to enter the same name when we for our Primary Data Container on any future XYZ virtualized versions regardless of what the .EXE entry point is named?
   

[TobyFruthParson]

My two cents:

From page 48 of the ThinApp 4.7 manual PDF:

Update Firefox 2.0.0.3 to Firefox 3

1. Capture Firefox 2.0.0.3 and Firefox 3 into separate packages.

2. Verify that the primary data container name is the same for both packages.  The primary data container, determined during the setup capture process, is the file that contains the virtual file system and virtual registry. If you have a Firefox 2.0.0.3 package that has Mozilla Firefox 2.0.0.3.exe as the name of the primary data container, and you have a Firefox 3 package that has Mozilla Firefox 3.dat as the name of the primary data container, change the name in the Shortcut parameter to a common name. For example, you can use Firefox.exe as a name.

From page 49:

Maintaining the Primary Data Container Name with Application Sync

The Application Sync utility requires that the name of the primary data container, the file that stores virtual files and registry information, is the same for the old and new versions of an application. For example, you cannot have an old version with Microsoft Office Excel 2003.exe as the primary data container name while the new version has Microsoft Office 2007.dat as the primary data container name. To verify the name of the primary data container, see the ReadOnlyData parameter in the Package.ini file. For more information about the primary data container, see “Defining Entry Points as Shortcuts into the Virtual Environment” on page 15.

From personal experience:  searching VMware's site for "Optional" or "RequiredAppLinks", you will find threads and posts stating you must use a DAT file for AppLink functionality to work.  I recommend using DAT files.  Seems to me they are nedded more often than not, so I always create a DAT file.

[ScottPart]

Toby,

Thank you for the response and the page number from the manual. That helped answer our question. Also Thank you for tip regarding AppLink and .DAT files. That also helps.

[TobyFruthParson]

You're welcome. Consider that my environment and setup and requirements may be different from yours.

This article may also prove helpful:

http://blogs.vmware.com/thinapp/2010/05/thinapp-updating.html