WuhuIslandTesting/Library/PackageCache/com.unity.addressables@1.21.12/Documentation~/editor/profiles/ProfileVariables.md

---
uid: addressables-profile-variables
---

#Profile Variables
Profile variables are generic key/value combinations that you can use to quickly alter Addressables configurations for different development situations.

There are two types of Profile Variables - standard, and path pairs.  Standard variables are standalone key/value pairs.  Path pairs use a special naming convention to connect sets of variables together.

Path pairs are typically used to switch between different build and load paths for different development situations.  For example, you could use path pairs to modify the build and load paths for your Addressable content for various platforms. 

## Adding a new standard variable

You can add two kinds of variables to your profiles: 

* A basic variable, which defines a single value
* A path pair, which defines a set of two path values. One value is for the build path and one is for the load path

You can use basic variables as components of your path values (for example, **BuildTarget**) and you can use them in your own build scripts. Use path pair variables to set the **Build & Local Paths** setting of your Addressables [Groups] and [remote catalog]. 

To add a new Profile variable, select either **Variable** or **Build Load Path Variable** from the **Create** menu. Assign the new variable a name and value, then select **Save**. Addressables then adds the new variable to all profiles.

Right-click (macOS: cmd + click) on the variable name to rename or delete the variable.

### Path Pairs

Path pairs define a matched set of `BuildPath` and `LoadPath` variables. When you create a path pair, you can use the pair name to assign the [path setting] of an Addressable [Group] or remote catalog as a unit. 

To create a path pair, go to **Create** and select **Build Load Path Variables**. Assign the path pair a prefix name and assign path strings to the individual fields. 

![](../../images/addr_profiles_pair_prompt.png) <br/>*A new path pair*

The new path pair uses the **Custom** setting for the **Bundle Location** property with your initial values. You can change to a different **Bundle Location** if needed.

> [!TIP]
> You can convert two regular variables for the build and load paths into a path pair by renaming them in the Profile window. Set one to `VariableName.BuildPath` and the other to `VariableName.LoadPath`.

![Path pairs grouped by a common prefix and separated by a period.](../../images/ProfilesWithPathPairsExample1.png)</br>
_The **Addressables Profiles** window showing two profiles with two path pairs._

### Default path values

The default values for the build and load paths are:

* Local build path: `[UnityEditor.EditorUserBuildSettings.activeBuildTarget]`
* Local load path: `[UnityEngine.AddressableAssets.Addressables.BuildPath]/[BuildTarget]`
* Remote build path: `ServerData/[BuildTarget]`
* Remote load path: `http://localhost/[BuildTarget]`

In most cases, you should not change the local path values. The Unity build system expects the AssetBundles and other files to exist in the default location. If you change the local paths, you must copy the files from the build path to the load path before making your Player build. The load path must always be within the Unity `StreamingAssets` folder.

If you distribute content remotely, you must modify the the remote load path to reflect the URL at which you host your remote content. You can set the remote build path to any convenient location; the build system does not rely on the default value. 

## Profile variable syntax

All Profile Variables are of type "string". You can assign them a fixed path or value. You can also use two syntax designations to derive all or part of a variable's value from static properties or other variables:

* __Brackets [ ]__:  Addressables evaluates entries surrounded by brackets at build time. The entries can be other profile variables (such as [BuildTarget]) or code variables (such as [UnityEditor.EditorUserBuildSettings.activeBuildTarget]). During a build, as it process your groups, Addressables evaluates the strings inside brackets and writes the result into the catalog.
* __Braces { }__: Addressables evaluates entries surrounded by braces at runtime. You can use code variables of runtime classes (such as {UnityEngine.AddressableAssets.Addressables.RuntimePath}).

You can use static fields and properties inside either the brackets or braces. The names must be fully qualified and the types must be valid in context. For example, classes in the UnityEditor namespace can't be used at runtime. For more information about namespaces, see Microsoft's [Namespaces](https://docs.unity3d.com/Manual/Namespaces.html) documentation.

The code variables used in the default Profile variable settings include:

* [UnityEditor.EditorUserBuildSettings.activeBuildTarget]
* [UnityEngine.AddressableAssets.Addressables.BuildPath]
* [UnityEngine.AddressableAssets.Addressables.RuntimePath]

For example: 
A load path of `{MyNamespace.MyClass.MyURL}/content/[BuildTarget]` is set on a group that creates an AssetBundle called "trees.bundle". During the build, the catalog registers the load path for that bundle as `{MyNamespace.MyClass.MyURL}/content/Android/trees.bundle`, evaluates `[BuildTarget]` as "Android", and adds the AssetBundle name to the path. At runtime as the Addressables system processes the catalog it evaluates `{MyNamespace.MyClass.MyURL}` to produce the final load path, `http://example.com/content/Android/trees.bundle`. 

> [!NOTE]
> Referencing a runtime variable in a Profile string doesn't prevent Unity from stripping that variable from your applications’ runtime libraries during the build optimization phase (if nothing else in your code references the same variable). See [Managed code stripping] for more information on how to prevent a class or member from being stripped.