App-V 5: On Environment Variables
Environment variables are managed on a per-package basis in App-V 5 just as they have with previous versions. During sequencing, the Environment Variable Virtualization Subsystem (say that 10 ten times fast) will capture snapshots of the user and system variable list before and after the monitoring process. Then lists are compared and any differences are added to the package manifest. This means the package will default to the variable data entered in during sequencing. The variables are then stored in the package manifest using the following format:
<appv:Include>
<appv:Variable Name="TMP" Value="[{LocalAppData}]\Temp" />
</appv:Include>
Where the “Name” is the variable and “Value” is the new, tokenized (if necessary) value of the environment variable. On the client, the named variable will be set to the new value within the virtual environment and properly translated.
The one time there is an exception to this process is when the PATH value is being handled. Applications never “set” the PATH variable – they only append, or add to it therefore if changes to the PATH value are detected during sequencing, the changes will be captured and will appear slightly different in the manifest, with a self-referential value. The PATH variable that is captured in manifest will look similar to:
<appv:Variable Name="PATH" Value="<dirpath1;%PATH%;dirpath2" />
Where dirpath1 would be a prefixed Path segment to the current PATH and dirpath2 is a suffixed path segment to the current PATH.
The sequencer can also detect the deletion of existing variables and will apply those in the manifest using the following format:
<appv:Delete>
<appv:Variable Name="TEMP" />
</appv:Delete>
In this case, the Environment Variable TEMP will be deleted within the virtual environment of the application.
These captured values can be modified and overridden using dynamic configuration. An administrator can modify DeploymentConfig and/or UserConfig to edit Environment Variables. The <Include> element beneath the <EnvironmentVariables> section is where new or modified variables should be placed. The <Delete> element is where values need to be removed. In the example below, the PATH variable is modified, two additional variables are added and one will be deleted (if exists.)
The Virtual Environment Variable Subsystem reads the package manifest and the option deployment and user dynamic configuration files, and produces two lists – variables to add and variables to remove. This is all done when the application launches. As the catalog documents are processed, newly processed values overwrite previously processed values, so last writer wins. It is important to make sure all needed variables from the manifest are transferred over to the dynamic configuration files when leveraging them to change variables post-sequencing.
As with sequencing, there is an exception and it again involves the PATH variable. The PATH variable is injected after a process has completely loaded. This is why it is not a good idea to try to use the PATH value to help a virtual application to find a static binary dependency (even inside the immutable package cache.)
Caveat with Connection Groups
An area that confuses sequencers is how environment variables are handled with Connection Groups. Environment variable lists overwrite each when combining packages into Connection Groups. Like with registry convergence, variable convergence is a last writer win scenario in the case of overlapping variable names. The package with the highest order within the connection group descriptor document wins variable name conflicts.
Exception with Multi-String Values
Be advised though that some variables are treated specially, as they have been identified as having multi-string values. If a multi-string variable is present in multiple packages, the resulting value is the combination of values from all packages, instead of the last writer winning. The list of variable names which are treated as multi-strings is stored in the registry at HKLM\SOFTWARE\Microsoft\AppV\Subsystem\EnvVarMultiStrings
Exception with Cross-Bitness
App-V deploys special additional tokens used to denote information that has to be adjusted depending on the bitness of the sequencing machine and the correlation of the client machine. These tokens apply to environment variables impacted by Wow64 redirection. They enable the proper translation when an application that was sequenced on a 32-bit machine gets deployed on a 64-bit client machine.
The two are:
AppVEnvironmentVariableCommonProgramFiles: Can be %commonprogramfiles% or %CommonProgramFiles(x86)%
AppVEnvironmentVariableProgramFiles: Can be %ProgramFiles% or %ProgramFiles(x86)%
The rules for this are as follows:
If the application is a 32-bit application, sequenced on a 32-bit operating system, deployed on a 32-bit operating system, then these tokens are expanded back to the original values.
If the application is a 32-bit application, sequenced on 32-bit operating system, deployed on 64-bit operating system, then these tokens are expanded back to X86 versions of the values.
If the application is a 64-bit application, sequenced on 64-bit operating system, deployed on 64-bit operating system, then these tokens are expanded back to the original values.
Verification of Virtual Environment Variables
When testing environment variables within a virtual application package, the environment variables will not be visible outside of the virtual environment. That is why you will see no changes when you list the variables using the internal “set” command:
However, when you open the command prompt inside of the virtual environment, you will see the variables from above:
