AppSync is a great update mechanism for certain use cases (more information on the AppSync feature can be found here). When you have deployed a new version is it very likely you want to perform a new thinreg registration on the package. AppSync has built in support for thinreg. If you place thinreg.exe on your AppSync URL will AppSync automatically perform registration of your new version.
Recently I was asked if the ThinApp SDK can be utilized to force an AppSync update on a ThinApp Package. More importantly, some customers have wanted to know if it was possible to change the AppSync URL on the fly.
So….I thought I’d share this script. 🙂
One of our developers have posted a sample code that uses the ThinApp SDK to create a true silent AppSync operation.
You'll find it here: http://communities.vmware.com/docs/DOC-13699
When your package use a .dat file as the primary datacontainer and you want to use AppSync it is important that the primary datacontainer name is not shared by one of the Entry Points.
Example that will not work with AppSync:
Shortcut= Mozilla Firefox.dat
Example that will work with AppSync:
Since we get a number of questions on how to use AppSync as well as how it can be utilized, specifically around ThinApp packaged applications such as Office or Adobe CS which are not a single executable like Firefox, Opera, or Adobe Reader, we figured it best to create a video to review how AppSync works, show how to use AppSync in general, show how to use AppSync with packaged apps having separate data container files and/or multiple entry point EXEs, and discuss what is required when needing to have clients download just the differentials vs. the whole updated ThinApp packaged app (i.e. slow links, remote/home users/etc.).
This document provides general information around using the ThinApp AppSync parameters to download ThinApp updates.
This method could be used to AppSync packages that are being streamed
(accessed from a network share). Schedule the AppSync.exe on the
fileserver and the fileserver is updating the packages automatically.
Since we are using AppSync it is only the differences that are being
downloaded and therefore you will have limited payload on the WAN/LAN.
- The .asd file is used for keeping track of when last checked the AppSync location
- The .asl file is used to keep track of how much we downloaded and it contains a list of block signatures for the new file (we use these block signatures to find blocks that we can copy from the existing old file)
- The .ase is the complete new updated file waiting to be applied as the .exe file (contains blocks both from the old .exe file and from the update file)
If a download is interrupted during AppSync it continues where it left of the next time the user launches the application.
The location of the AppSync log and cache files can be specified within package.ini and with the parameter "UpgradePath=".
UpgradePath is also used for specify the location for integer updates.
AppSync allows you to update your ThinApp applications via http or https. However, we don’t always have a web infrastructure to use or perhaps we would rather use a file share or replicated share like DFS or a NAS device. With AppSync, you can use these types of locations for the AppSyncURL= field. Remember, all we need is a URL location specified for the feature to work, so if you want to use a file share, follow these guidelines for your configuration of choice.
For a UNC:
\\server\share\path\to\file “convert this to” file://server/share/path/to/file
For a Local path:
c:\path\to\local\file “convert this to“ file:///c:/path/to/local/file (note there are 3 slashes following file: here)