Search the VMware Knowledge Base (KB)
View by Article ID

Enabling VMware ThinApp virtual applications for Horizon Application Manager with the relink command (2021928)

  • 4 Ratings

Purpose

This article describes the enhanced relink command available from ThinApp 4.7.2 on. Relink has a new -h flag, which is primarily for enabling a ThinApp package for use in Horizon Application Manager. Relink -h has other useful functions, too.

Resolution

ThinApp 4.7 was the first release to support ThinApp virtualized applications offered through the VMware Horizon Application Manager. To enable a ThinApp package for Horizon, ThinApp Setup Capture was enhanced to include a Horizon enablement window, and you set up a ThinApp Repository of virtualized applications in the Horizon environment. For details on configuring ThinApp packages for Horizon and setting up the Horizon environment to include ThinApp packages, see the VMware ThinApp Reviewers Guide and the blog post VMware ThinApp 4.7: What's new?.

Before ThinApp 4.7.2, f you wanted to enable for Horizon a previously packaged ThinApp virtual application, you needed to do one of the following:

  • Recapture the application with Setup Capture from ThinApp 4.7 or later
  • Manually configure Horizon parameters in Package.ini, then rebuild with ThinApp 4.7 or later

For more information about why you might still want to use those methods, see Enabling for Horizon a previously packaged VMware ThinApp virtual application, without relinking (2030595).

With ThinApp 4.7.2, you can now easily enable for Horizon a previously captured package, without needing to run Setup Capture again and without reconfiguring Package.ini and rebuilding the application.

How does ThinApp 4.7.2 allow you to enable packages for Horizon?

ThinApp 4.7.2 adds functionality to the ThinApp relink command so that you can easily enable previously virtualized applications for Horizon. The relink command itself is not new. It is provided with the other ThinApp executables in the ThinApp Program Files directory.

Relink updates previously packaged applications to the new ThinApp runtime. For details on the relink command which are not specific to Horizon enablement, see the Knowledge Base article VMware ThinApp relink command to update the ThinApp runtime of a virtual application.

With ThinApp 4.7.2, a new '-h' flag for the relink command enables for Horizon a previously packaged ThinApp application.

Important: The ThinApp runtime is always updated when you run relink -h on a ThinApp package, even though this may not be your requirement when enabling for Horizon.

Why would you want to use relink -h to enable a previously packaged ThinApp application for Horizon?

Other ways of enabling a package for Horizon are:

  • Recapture with Setup Capture from ThinApp 4.7 or later
  • Edit Package.ini to include the Horizon parameters, and rebuild with ThinApp 4.7 or later

(For details on these other methods, see Enabling for Horizon a previously packaged VMware ThinApp virtual application, without relinking.)

However, relink -h is the easiest and fastest way to enable a previously packaged ThinApp application for Horizon. Use relink -h when you:

  • Need to update only the ThinApp runtime, perhaps to incorporate a bug fix in the new ThinApp version
  • Do not have the application project folder

What is the basic syntax for the relink -h command?

The main use of relink -h is to enable a package for Horizon; use the basic syntax of:

relink -h <package>

You can run the relink command from the ThinApp Program Files directory to get help on syntax:

Relink -h has these two basic functions:

  • Enables for Horizon, or retains enablement for Horizon
  • Updates the package to the new ThinApp runtime

Relink -h is the basic command to enable a ThinApp package for Horizon, and it also updates the runtime. However, you may notice the other variations of relink syntax.

Beyond Horizon enablement, you can create updated packages with relink -h. The relink -h command syntax includes two additional flags that work together to help you create updated ThinApp packages for Horizon:

  • AppID
  • VersionID

AppID allows you to specify a GUID for the application identifier. VersionID allows you to specify a version number for the package. For details on the AppID and parameter, see Enabling for Horizon a previously packaged VMware ThinApp virtual application, without relinking. For details on the VersionID parameter, see Updating VMware ThinApp virtual applications in Horizon Application Manager.

For example, if you use relink -h on a previously Horizon-enabled package and retain the same AppID, and you assign a new VersionID, you can place the package on the ThinApp Repository in a new folder, and Horizon recognizes the higher VersionID as a marker for the updated package.

Relink -h is one way to create updated packages for Horizon; using Setup Capture and direct editing of Package.ini are two other ways to create updates. For more information about these two other ways of updating ThinApp packages in Horizon, see Updating VMware ThinApp virtual applications in Horizon Application Manager.

What are some key points to remember about relink -h syntax?

Here are some important points about relink -h syntax:

  • With relink or relink -h, you can specify the path to a single executable or to a folder of executables. You can wildcard a directory to relink all executables in that directory. A wildcard causes relink to operate on all EXEs, MSIs, and the DAT file in the specified directory and to ignore other files.

    However, with relink -h, the folder (or directory) you point to must contain files for only one virtual application package. When you use the -h flag with relink, never specify multiple bin directories or use the Recursiveflag because executables for different applications would be assigned the same AppID in Horizon.

  • If the executable name includes spaces, you must quote the executable string

  • You need to point the relink command to all of the applications EXE and DAT files that you will use in Horizon. The best way to do this is to use:

    relink -h <folder>/*.*
  • If you point relink to a folder of executables, relink applies the same AppID and VersionID to all of the executables in the folder

    • Specifying a prior packages value for AppID enables you to retain the prior packages entitlements and shortcuts in Horizon. For details, see How do you find the AppID of a ThinApp package enabled for Horizon?

    • You do not need to rebuild the application after running relink

    • With relink, you cannot point directly to the folder of package executables on the CIFS share in the Horizon environment. Relink converts the old executables to .bak files when it updates the runtime, and it writes those .bak files, as well as the new files, to the folder. The ThinApp Repository in the Horizon environment should be read-only. Therefore, you must point relink to a copy of the folder of executables.

    • Relink does not look at, read, or write the InventoryName Package.ini parameter. When you run relink on a package, whether previously Horizon-enabled or not, the InventoryName is not touched, therefore is retained.

    • You cannot run relink -h from a ThinApp version prior to 4.7.2. The -h flag was not implemented before ThinApp 4.7.2.

How does relink -h set or change Package.ini parameters?

If the package was not previously enabled for Horizon, relink -h:

  • Generates a random AppID

  • Does not set VersionID (it is understood to be 1 when not set)

  • Sets the NotificationDLLs value to HorizonPlugin.dll, the default

  • Retains the prior value for InventoryName

  • Does not set a value for HorizonOrgUrl. If you want this parameter set, you must edit Package.ini.

If the package was previously enabled for Horizon, relink -h:

  • Retains the value for AppID

  • Retains the value for VersionID

  • Retains the value for NotificationDLLs, which is always HorizonPlugin.dll

  • Retains the value for InventoryName

  • Retains the value for HorizonOrgUrl, if set

Relink does not change the values of the Horizon parameters in Package.ini, but instead builds the parameter values into the executables. Relink operates on the old executables and does not touch Package.ini and the project directory. If you examine Package.ini, it retains the old parameter values. If you want to use the old project folder later, you must assign values to the Horizon parameters. The new executable is independent of the prior project directory, including Package.ini.

What is a way to think about the variations on the relink syntax?

Because of the AppID and VersionID flags, and the option of running relink -h on a package that is either not Horizon-enabled or already Horizon-enabled, a number of outcomes from relink -h are possible.

If you run relink -h on a package that is already enabled for Horizon, all previous Horizon parameters are retained, except for those overwritten by any relink command flags. (Similarly, if you run relink without the -h flag on a package that is already enabled for Horizon, all Horizon parameters are retained.) This means that the old packages AppID and VersionID can be retained or overwritten.

Following are the outcomes and the rules for their placement on the ThinApp Repository in Horizon:

  • New Horizon package: The package has a different AppID from any already in Horizon. Place the new package in a new folder on the ThinApp Repository.

  • Replacement package: The updated package has the same AppID as another package in Horizon. Replace the old package with the updated one within the old folder.

  • VersionID-updated package: The updated package has the same AppID as a prior package in Horizon, but a higher VersionID. Create a new folder for the updated package on the ThinApp Repository, and keep the old folder also.

The following table explains the functionality, use cases, and ThinApp Repository placement for each relink command variation applied to a non-Horizon-enabled package or a previously Horizon-enabled package.

Relink Command Variations: Functionality, Use Cases, and Deployment

 

"Horizon-enabled package" = enabled and on the ThinApp Repository

What It Does

 

New Horizon Package (New Folder) *

 

Horizon Replacement Package (Old Folder) **

 

Horizon VersionID-Updated Package (New Folder) ***

 

Use Cases

 

relink <non-Horizon-enabled package>

Updates the runtime, does not enable for Horizon. (If you want to enable for Horizon, you must use the -h flag.)

N/A

 

N/A

 

N/A

 

You want to update the ThinApp runtime for a non-Horizon-enabled package, perhaps to incorporate bug fixes (conventional use of relink)

relink <Horizon-enabled package>

Updates the runtime, retains the Horizon parameter settings

No

 

Yes

 

No

 

You want to update the ThinApp runtime for a Horizon-enabled package, perhaps to incorporate bug fixes

relink -h <non-Horizon-enabled package>

Enables for Horizon, updates the runtime

Yes

 

No

 

No

 

You want to enable a package for Horizon (and incorporate the new ThinApp runtime into the package)

relink -h <Horizon-enabled package>

Updates the runtime, retains the Horizon parameter settings

No

 

Yes

 

No

 

You want to update the ThinApp runtime for a Horizon-enabled package, perhaps to incorporate bug fixes

relink -h -AppID <{GUID}> <non-Horizon-enabled package>

Enables for Horizon, assigns the specified value to AppID, updates the runtime

Yes if assigned AppID is new. No if assigned AppID is already in Horizon.

No if assigned AppID is new. Yes if assigned AppID is already in Horizon.

No

 

You want to replace the old version of a package with a package you updated and tested outside the Horizon environment. As a final stage, you need to enable the package for Horizon and assign the same AppID as for the old package.

relink -h -AppID <{GUID}> <Horizon-enabled package>

Example

relink.exe -h -AppID {5C86FD1C-E0EC-4B06-9BE6-ED4C211B3DCD} "Mozilla Firefox.exe"

Updates the ThinApp runtime, retains all Horizon parameters, except substitutes the specified AppID value

Yes if assigned AppID is new. No if assigned AppID is already in Horizon.

No if assigned AppID is new. Yes if assigned AppID is already in Horizon.

No

 

1) You already updated the package to the new version of ThinApp to incorporate a bug fix and tested the package outside Horizon. Now you need to enable for Horizon and point to the package you are replacing, with the old package AppID. 2) You want to assign a different AppID from the original executable to test the old and new packages within Horizon. 3) You want to replace a prior Horizon-enabled package that is no longer working (use the same AppID).

relink -h -AppID <{GUID}> -VersionID <integer> <non-Horizon-enabled package>

Enables for Horizon, assigns the specified AppID and the specified integer to VersionID. Also updates the runtime.

Yes if assigned AppID is new. No if assigned AppID is already in Horizon.

No if assigned AppID is new. Yes if assigned AppID is already in Horizon, and VersionID is the same as for that package.

Yes if assigned AppID is already in Horizon, and VersionID is new. No if assigned AppID is new.

You want to update the old version of a package on the ThinApp Repository with a package you updated and tested outside the Horizon environment. As a final stage, you need to enable the package for Horizon, assign the same AppID as for the old package, and increment VersionID to indicate an updated package.

relink -h -AppID <{GUID}> -VersionID {+|<integer>} <Horizon-enabled package>

Updates the runtime, retains all Horizon parameter settings, except overwrites the previous value of AppID with the specified GUID and overwrites the previous value of VersionID with the specified integer

Yes if assigned AppID is new. No if assigned AppID is already in Horizon.

Yes if assigned AppID is already in Horizon, and VersionID is the same as for that package. No if assigned AppID is new.

No if assigned AppID is new. Yes if assigned AppID is already in Horizon, and VersionID is new.

Mostly useful for testing. You want to update the runtime for a Horizon-enabled package, perhaps to incorporate bug fixes, and you want to assign a different AppID from the original executable, possibly to test the old and new packages side by side within Horizon. And you set the VersionID to a new value, which may be useful under some testing circumstances.

relink -h -VersionID {+|<integer>} <non-Horizon-enabled package>

Enables for Horizon, increments the previous value of VersionID by 1, or you set the value for VersionID; updates the runtime

Yes

 

No

 

No

 

You want to replace the old version of a package with a package you updated and tested outside the Horizon environment. As a final stage, you need to enable the package for Horizon and assign the VersionID.

relink -h -VersionID {+|<integer>} <Horizon-enabled package>

Updates the runtime, retains all Horizon parameter settings, except increments the previous value of VersionID by 1, or you set the value for VersionID

No

 

No if VersionID is new. Yes if VersionID is the same as for the old package.

Yes if assigned VersionID is new. No if assigned VersionID is the same as for the old package.

You want to update the runtime for a previously Horizon-enabled package, perhaps to incorporate bug fixes, and create an updated version with a specific version number, perhaps to reuse a former VersionID.

* Create a new folder on the ThinApp Repository for the new package. Follow the standard instructions for placing the executables in a folder on the ThinApp Repository in the Horizon environment (see the VMware ThinApp Reviewers Guide). You must configure user entitlements to the package. Horizon will initiate registration and creation of shortcuts.

** Replace the prior executable with the updated one, in the old folder on the ThinApp Repository. The AppID for the updated package is the same as for the old package, and there is no new VersionID. The application entitlements and shortcuts are preserved.

*** Create a new folder on the ThinApp Repository for the VersionID-updated package. The AppID for the updated package is the same as for the old package, and there is a new VersionID. The application entitlements and shortcuts are preserved.

For full details on updating ThinApp packages in the Horizon environment, with relink or another method, see Updating VMware ThinApp virtual applications in Horizon Application Manager.

What is the role of the Package.ini parameter InventoryName with relink -h?

For replacement updates or VersionID updates in Horizon, the value of InventoryName must be the same for the old package and the updated package, just as the value of AppID must be the same. The Horizon Service uses InventoryName to identify packages. Relink -h retains the value of InventoryName for the target package, but if you are using the output of the relink -h command as an update, be careful that the InventoryName of the updated package matches the InventoryName of the prior package.

How do you find the AppID of a ThinApp package enabled for Horizon?

When you use the relink command to create an updated package for Horizon, you sometimes need to know the AppID of the prior ThinApp package that you are updating.

If you used Setup Capture to enable the package for Horizon, the default value of AppID is genid, which causes ThinApp to generate a random AppID for the package during the build. (If you had wanted to specify the value for AppID, you could have stepped out of Setup Capture and edited Package.ini to enter a GUID value for AppID.) If the value of AppID is genid, Package.ini does not record the randomly generated value. Instead, Package.ini shows genid as the value for AppID. The value for AppID is embedded in the application executable during the build.

You must use the ThinApp SDK to expose the value of AppID that is within the executable. For information on using the ThinApp SDK, see the VMware ThinApp SDK.

If you manually entered a GUID as the value for AppID, you can read the value of AppID in Package.ini.

Can you use a Horizon-enabled ThinApp package outside of Horizon?

No. A ThinApp package enabled for Horizon can be used only in a Horizon implementation. If no Horizon Agent is installed on an endpoint, when the user tries to launch the Horizon-enabled ThinApp package through a shortcut, the package does not launch, and the user receives an error message about no Horizon Agent.

See Also

Update History

13 July 2012 (TdeB): Clarification on relink -h and multiple folders of executables.

Request a Product Feature

To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page.

Feedback

  • 4 Ratings

Did this article help you?
This article resolved my issue.
This article did not resolve my issue.
This article helped but additional information was required to resolve my issue.

What can we do to improve this information? (4000 or fewer characters)




Please enter the Captcha code before clicking Submit.
  • 4 Ratings
Actions
KB: