About once a month, I get asked: What are the GUIDs for?
Application Streaming uses GUIDs to identify execution targets of a profile. These are most visible as the RadeCache sub-directory names that hold the execution image of an application.
In this post, I'll remove some of the mystery and provide the rationale behind their use.
Background:
GUID = Globally Unique IDentifier. The more correct term is UUID = Universally Unique Identifer. I'll stick with GUID.
Application Streaming has a few components which are key for this discussion.
- Streaming Profiler
- Streaming Client
- Application Hub (Fancy name for a file server)
The job of the Streaming Profiler is to create an application profile and store that profile on the file server where it can be seen by the clients for execution and where it can be referenced by the Access Management Console for publishing.
Profile: XML file that describes things that can be published.
Target: CAB file that holds the content used to actually run an application.
The profile holds a list of application names and a set of icon data that go with the applications. Notice that this is all the information that is needed by the Access Management Console when publishing applications.
The target holds everything needed by the Streaming Client for purposes of actually running an application. It holds the file system and registry data that was collected during the profiling process or more precisely, it holds the stuff that was intercepted when an installation program was run under the Streaming Profiler.
Notice that a single profile can support multiple execution targets.
Minimal number of icons
An Application Streaming design goal was that a single publishable application (name and icon), could support multiple execution images where the "correct" execution image could be runtime selected from a list that is carried along with the profile.
Consider creating a profile of the Mozilla Firefox browser and profiling the installer twice, once for 32-bit execution and a second time for 64-bit. The following is a high level view of what is in the profile.
Profile: Firefox
- Application 1: Firefox
- Application 2: Firefox Safe Mode (right, we don't publish that one)
- Icons
- "Target 1": (The 32-bit target) and
- "Target 2": (The 64-bit target)
In theory, we could create a directory for the profile and then subdirectories for the execution images. Example:
- Firefox\
- Firefox\Target 1
- Firefox\Target 2
It gets complicated when you consider that the association of Target 1 with the 32-bit systems and Target 2 with the 64 could actually change as the profile evolved.
Targets are associated with client execution machines on several factors, including:
- Boot drive letter
- Language of OS
- Operating System version
The target that is "correct" for Windows XP 32-bit English right now, may later be the correct target for Windows XP and Vista 32-bit English and German. Then the following week, it may drop German and add Japanese or all languages and figure out that the Vista execution really needs to be in its own Target and have a 3rd created.
Using numeric integer target names would work (1, 2, 3, 4), but this gets a bit strange when Targets are erased from a profile. It also fails to satisify a second requirement of the isolation system. By design SaveAs creates a new target that will never conflict with the target that was opened for editing.
A profile is "new" if it is created or if a file / SaveAs occurs. The Targets in a profile that is saved retains their identifier and targets that are SavedAs, receive a new GUID. This way, the caching system can use the GUID as the key to isolation and pretty much ignore the association of Targets to profiles. Since GUIDs are defined to always be unique, using GUIDs eliminates the complication of supporting two different versions of the same named profile with the same named set of targets.
What the Streaming Client needed
1) Target name must be unique and
2) Target name must never change
GUIDs fit perfectly.
Evolution
Once the GUIDs were selected as the names of the execution targets, they also serve as the basis of the directory names of the system shared cache and the per-user execution spaces that back up the layers of isolation. The GUIDs then also support unique identification of a specific Target associated with a specific profile.
It is worth noting that we describe the GUIDs that identify a execution target. Profiles also have a unique GUID and two profiles with the same name, but different GUIDs are ... different profiles.
This is why we did it. Feel free to throw some rocks.
Joe Nord
Product Architect - Application Streaming
Comments (2)
Feb 14, 2008
Chris De Jongh says:
Joe, if you only create a streamed app for running on XenApps only. Is th...Joe,
if you only create a streamed app for running on XenApps only. Is there any architectal reason why you cannot change the GUID of the streamed app to a meaningfull name? The reason why asking, if you want to use flexprofiles, it is much easier to use named registry values at hkcu\sw\citrix\radecache to export and import then GUID's.
And if it is supported by Citrix, what actions needs to be done to accomplish this.
Thanks for the feedback.
Chris
Feb 26, 2009
Joseph Nord says:
Just saw this, a year late, but I'll reply anyway. We struggled with this what...Just saw this, a year late, but I'll reply anyway.
We struggled with this what App Streaming was first developed. Here's the delima. Say you have a GUID 12345678 which identifies the Windows XP version of the target. You rename the target to WinXP and you're happy. Next week, you decide that this target will also work with Windows 2003. So, you go back and change the name. Well, no you don't. You could also later decide that the 2003 and XP versions should be separate, but that the existing XP2003 Target should become the 2003 target and a new one will be XP.
It gets worse - RADE means Rapid Application DElivery, and it supports changing applications without kicking users off of the machine. How do you rename the targets without kicking people off?
The GUID that identifies the target directly ties into the streaming cache management. Change the GUID, all the cache locations have to change too. The caching system doesn't care which target represents what, but it absolutely insists that the name of the target doesn't change.
It gets worse: What if you have a profile on a file share, which you edit and "save as" to a new file share, but with the same name. The before/after profiles are same named, with same capabilities and equivalent Targets, but they must evolve SEPARATELY. Say they forked at version 3. When you get to version 8, they won't necessarily have the same contents and while they could be published from two different places, with the same application names and same list of Targets, the execution contents must be different. Because of this, the profiler changes the GUID on a SaveAs, but leaves the GUID unchanged on a "Save".
Bottom line: Once we decided to support multiple execution images per named "profile", the identifier that describes the target had to be unique and never change for the life of the profile. A GUID fit that need, though it is rather unpleasant to look at.
Add Comment